Re: Mac-on-Linux and VM internals
Re: Mac-on-Linux and VM internals
- Subject: Re: Mac-on-Linux and VM internals
- From: Jim Magee <email@hidden>
- Date: Tue, 9 Mar 2004 12:40:57 -0500
On Mar 9, 2004, at 11:35 AM, Samuel Rydh wrote:
>
On Tue, Mar 09, 2004 at 10:11:41AM -0500, Jim Magee wrote:
>
>
>
> On Mar 7, 2004, at 10:34 AM, Samuel Rydh wrote:
>
>> In order to maximize speed, MOL works at a very low level. Basically
>
>> MOL hooks all exception vectors (in an OS independent manner) and
>
>> takes
>
>> complete control over the MMU. The main benefit is speed (the MMU
>
>> virtualization
>
>> costs almost nothing).
>
>
>
> Hmmm. In the first paragraph you state that you are doing probably
>
> the
>
> most unsupported thing possible. And you are worried about using a
>
> handful of not-guaranteed-to-be-supported-long-term SPIs in the
>
> second?
>
> Interesting. ;-)
>
>
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? What if one of the other CPUs
is accessing the exception vectors you are changing at the time?
What happens when we load two different MOL-like products' KEXTs at the
same time? Won't they get in each other's way? What if we decide,
later on, to change the exception handlers we have installed (maybe to
more optimized versions for the platform)? Won't we overwrite yours?
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 (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).
I know you probably know all that already. But I just wanted to keep
you a little more honest. ;-)
>
(*) The _only_ OS dependencies are the following:
>
>
i) Availability of the hash table lock (to guard against two
>
simultaneous
>
tlbsync which might deadlock on SMP systems).
>
>
ii) Which SPRGs are used as scratch register by exception handlers
>
(Linux uses SPRG0/SPRG1, Darwin uses SPRG3 and partially SPRG2).
>
>
iii) MOL needs a VSID range which is not used by the kernel.
>
>
> Note that we went out of our way NOT to take your/MOL's approach in
>
> supporting other virtual machines in Darwin/Mac OS X.
>
> And we did it for the reason I just mentioned: it results in a
>
> pretty unsupportable
>
> situation long-term (especially if binary compatibility of the KEXTs
>
> doing this sort of thing is required).
>
>
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? How much of it has to be in the kernel address
space? 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? How compact is
the code that actually intervenes with the rest of the system? Or more
importantly, how entangled is it with the rest of the MOL code? Your
original statement about needing to wire down all of MOL to keep the
system running seems somewhat telling in this regard. What if someone
suspended a thread running inside the MOL task (maybe with a debugger)?
Would the system keep running? Are there key places where it
wouldn't?
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."
--Jim
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
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.