Re: Mac-on-Linux and VM internals
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 | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.
participants (1)
-
Jim Magee