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: Thu, 11 Mar 2004 13:41:58 -0500
On Mar 9, 2004, at 9:19 PM, Samuel Rydh wrote:
>
On Tue, Mar 09, 2004 at 12:40:57PM -0500, Jim Magee wrote:
>
>> 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...
I must disagree. We have one kernel. It must boot on as many CPUs as
possible (currently all CPUs we support). So, the initial exception
vector implementations are somewhat generic (and support the
worst-case). Once we detect exactly what system we are on (presence of
multiple CPUs or not, etc...) we may want to change these vector
settings to go directly to optimized versions for that platform (as
checking a set of "never changing state flags" in each exception
handler invocation can be considered wasteful). The platform KEXTs are
the only ones that know this information for sure - and we have to be
running for a while to run them.
So, there you go. A legitimate (although currently hypothetical) reason
we would need/want to do this. Because the platform KEXTs are just
KEXTs (like yours), and there is no explicit dependency between them,
it would be a race to see who got their changes in last (and I imagine
the platform KEXT wouldn't write the vectors itself, but instead inform
the base kernel of the presence [or absence] of key features, and we
would would update the vectors ourselves to one of a set of handlers we
already have defined in the base kernel).
>
> 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.
Sure, there are such suitable mechanisms in our kernel. They're just
at a much higher level than you want.
This all stems from divergent design philosophies. Our kernel believes
in providing "abstracted hardware" services to code that implements
other operating systems. Meanwhile MOL prefers to provide
non-abstracted pure virtual emulations of the hardware to other OSes.
While one can envision a layering of these two software systems, it
normally wouldn't be to have the abstraction-providing one sitting
underneath the pure-virtual one. But that's the situation we find
ourselves in - with the virtualizing software trying to pry the
abstraction-providing software away from the true hardware (with the
abstraction-providing software trying not to give up control).
--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.