Re: Mac-on-Linux and VM internals
Re: Mac-on-Linux and VM internals
On Tue, Mar 09, 2004 at 12:40:57PM -0500, Jim Magee wrote:
>
> Well, that is not quite true. MOL does take full control of the MMU but
>
> in a completely OS independent manner(*). New versions of
>
> OSX won't break this code. In fact, the same code is used both under
>
> Linux and OSX (so the code is truly kernel independent).
>
>
I'm sorry, but not to be picky, exactly how does your KEXT take control
>
of the exception vectors (after the system is running one OS) in a way
>
that is "totally independent" of the OS?
MOL relocates the very first instruction of each exception vector
(the instruction 0x200, 0x300 and so on) and inserts a branch to
the new exception vector.
>
What if one of the other CPUs
>
is accessing the exception vectors you are changing at the time?
That is safe. The other CPU will either run the old code or
take the branch to the new code (which essentially just branches back
to old code). Removing the hook is equally safe. After the branch has been
overwritten with the old instruction, no CPU can be in the MOL hook
once a few CPU cycles has elapsed.
>
What happens when we load two different MOL-like products' KEXTs at the
>
same time? Won't they get in each other's way?
Well, they would have to patch and depatch in the same order, opposite
order which would admittedly be a problem if one didn't coordinate things.
>
What if we decide, later on, to change the exception handlers we
>
have installed (maybe to more optimized versions for the platform)?
You mean, on the fly after the system has booted? Sound like a worse hack
than what MOL does without the (good) excuse that MOL can't easily make
modifications to the kernel proper...
>
Won't we overwrite yours?
Sure... but how realistic is that scenario?
>
All these issues require your solution to have knowledge of how the
>
"base" OS works - and usually in ways that the base OS isn't willing to
>
be exposed
I'm having difficulties seeing a "real world" case here...
>
(never mind the potential need for your KEXT to be
>
re-released for every new hardware platform that ships - as not all
>
these mechanisms are supported in a binary-compatible way between
>
hardware releases either).
Well, "every new hardware platform" is a gross ex-aggregation :-).
Sure, major new CPU features like AltiVec or the G5 needs to
be explicitly supported.
>
I know you probably know all that already. But I just wanted to keep
>
you a little more honest. ;-)
Well, there is one dependency which I did forget; MOL needs to be able to
allocate a few bytes of RAM within the range of an absolute branch
(it is impossible to safely patch the exception vectors otherwise).
>
> Actually, if the three points above were provided by the kernel then
>
> the MOL VM engine would be guaranteed to function. I bet that this
>
> is a lot less invasive than the current support for BlueBox :-).
>
>
Probably not under my definition of invasive.
>
>
If MOL goes out to lunch, what does the machine look like? Is there
>
any way to recover it?
Well, if there is a bug in the kernel module then it can obviously bring
down the system. However, the VM part of MOL is designed to be able
to report errors and continue gracefully even if a "catastrophic" event
like an unexpected exception should occur. In fact, MOL was able to
gracefully recover from the double exception hardware problem
(certain 750 models can take a double exception if both the TAU and the DEC
exceptions are enabled simultaneously) and print a meaningful error message.
I actually tracked down this hardware bug quite some time before it
got documented in a chip errata because I got the "MOL Internal Error..."
message...
>
How much of it has to be in the kernel address space?
The CPU and the MMU virtualization. Part of the CPU virtualization (i.e.
the emulation of certain supervisor instructions) could go into userspace
but the performance impact due to the double context switch makes
a bit expensive.
>
Does the user know it is MOL that went out to lunch (when it
>
does go out to lunch), or does it appear that the whole
>
system/Darwin/Mac OS X kernel have gone out to lunch?
Rhetorical question :-). Badly written kernel code will always
cause stability problems.
>
How compact is the code that actually intervenes with the rest of the system?
Well, MOL is split into two parts; the kernel module part and a userspace
process. The userspace code handles hardware emulation (e.g. emulates
the PCI bus), supports client side drivers, handles I/O and so forth.
It constitutes the bulk of the code and it runs as an ordinary user
process without any magic attributes.
The userspace process talks with the kernel module through an ioctl
interface (mostly to initialize and configure the virtual machine).
It also triggers the switch to virtualization mode (but the switch itself
is handled by the kernel module).
The kernel module it essentially a black box which does not talk much
with the rest of the world. It consists of two parts, the low-level
(assembly) code which handles exceptions and (essentially) runs with
the MMU off and the high-level C code which maintains the MMU
virtualization.
It is only the C-code that invokes external code. The only kernel
services used are atomic operations, memory allocations and spinlocks.
Well, MOL also has to be able to obtain the physical address of wired down
memory (the assembly code runs with the MMU off...).
>
Or more importantly, how entangled is it with the rest of the MOL code?
It is clearly separated.
>
Your original statement about needing to wire down all of MOL to keep the
>
system running seems somewhat telling in this regard.
No no... not the all of MOL. Just the virtualized RAM. The RAM has to be
wired down (currently) because the MOL module has no way of knowing
that a particular page is about to be swapped out (or whatever). If the
kernel module could be told (through some suitable mechanism) about this
event, then it would be trivial to flush any references to that page.
That is, MOL is designed to function as a software TLB cache with respect
to the operating system when pageable memory is used for RAM.
>
What if someone suspended a thread running inside the MOL
>
task (maybe with a debugger)? Would the system keep running?
Yes, no problem.
>
Are there key places where it wouldn't?
Nope.
>
Almost none of these things are issues with Classic/Virtual-PC, etc...
>
on Mac OS X. Sure, we pay a small performance hit as a result. But I
>
consider that "less invasive."
Well, you are comparing Apples with Oranges :-). Classic does not
really need a full blown MMU virtualization since MacOS 9 does not utilize
the MMU to any significant degree.
As for Virtual-PC... well, the huge performance impact here is the
CPU emulation. If the cost of emulating the MMU is of the same magnitude,
then it is probably an acceptable overhead.
For MOL the situation is very different (assuming a MMU demanding OS like Linux or
OSX is run within MOL). The CPU virtualization has close to zero overhead.
A costly MMU virtualization would really impact performance. The example
below should clarify my argument:
Virtual-PC: 1 virtual-pc cycle = 20 cpu emulation cycles + 5 mmu emulation cycles
MOL: 1 MOL-cycle = 1 instruction cycle + 5 mmu emulaion cycles.
That is, MOL's performance would be 1/5 of what it is today while VPC only
would only loose 20% of its speed... No doubt, the real-world numbers are a bit
different but this is the core of the issue.
/Samuel
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.