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 | 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.