Re: Mac-on-Linux and VM internals
Re: Mac-on-Linux and VM internals
On Thu, Mar 11, 2004 at 01:41:58PM -0500, Jim Magee wrote:
>
>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 somewhaOAt 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.
I agree that a platform expert KEXT might want to do this kind of
low-level manipulation...
>
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).
...but in all circumstances, this will happen way before MOL can
be started. MOL does not touch exception vectors until the userprocess
itself is started. And the platform KEXT will certainly have done
whatever it wants to do at this point. Probably even before init
is started.
Of course, in a perfect there would be either
a) exported hooks which MOL could use, or even better,
a mechanism where MOL could ask nicely to receive exceptions
when the CPU is in virtualization mode (e.g. when a special
flag bit is set in some SPRG register).
or b), a complete MMU virtualization engine in the kernel
providing enough support for it to be possible to implement
something like MOL in userspace.
>
>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.
I'm aware of that; I agree that this kind of API is not really
something you would not normally like to export externally. From an
architectural standpoint, this part of MOL should be probably be within
the boundaries of the kernel (just like the code the code that
supports Classic lives in the kernel proper) providing a well
defined API to userspace.
>
This all stems from divergent design philosophies. Our kernel believes
>
in providing "abstracted hardware" services to code that implements
>
other operating systems.
Which is obviously good; I have no argument there. What I'm saying is
that MacOS X does not provide _enough_ support for it to be possible
to write something like MOL without major performance/compatibility
sacrifices.
>
Meanwhile MOL prefers to provide
>
non-abstracted pure virtual emulations of the hardware to other OSes.
Yes... there are several benefits with this - in particular if one
doesn't have any control over the target OS. For instance, if
MOL only provided abstraced MMU services to the client OS, then
it would require changes deep into the core of the (client) kernel.
While this is how I would address the problem if I could easily get
changes of that kind into the kernel, it isn't really an option.
A pure virtualization is also _necessary_ if one wants to use MOL
for development/debugging of software targeted for a special hardware
platforms (embedded solutions come to mind).
That said, there is obviously nothing wrong with an abstracted APIs.
It is just a question of what you are trying to achieve. MOL provides
abstracted APIs for non-CPU related stuff (why emulate a
piece of hardware when it is simpler - and more efficient - to just
write a driver which talks to a suitable API?).
>
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.
I'm not completely sure whether you refer to MOL and the OSX kernel or
to MOL and the client OS here. I would say that MOL and MacOS X are
mostly sitting beside each other as is.
>
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).
Or like the virtualization software trying to use the hardware
behind the back of the kernel without it ever noticing...
/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.