Re: Mac-on-Linux and VM internals
Re: Mac-on-Linux and VM internals
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).
>
>
>
>... [snip] ...
>
>Also... the documentation explicitly states that vm_map_xxx can't be
>
>used safely
>
>from a KEXT. Why is that? I believe I don't have to use those
>
>functions but
>
>it would be interesting to know exactly why there is a difference
>
>between
>
>a KEXT and the kernel proper.
>
>
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).
(*) 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 :-).
/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.