> -----Original Message----- > From: arai@xxxxxxxxxx > Sent: Wednesday, March 22, 2006 5:34 PM > > > The idea of in-tree ROM code doesn't make sense. The entire point > > of this layer of code is that it is modular, and specific to the > > hypervisor, not the kernel. Once you lift the shroud and combine > > the two layers, you have lost all of the benefit that it was > > supposed to provide. > > To elaborate a bit more, the "ROM" layer is "published" by > the hypervisor. This layer of abstraction will let you take > a VMI-compiled kernel and run it efficiently on any > hypervisor that exports a VMI interface - even one that you > didn't know about (or didn't exist) when you compiled your kernel. > > [...] > > Going forward, having the ROM layer published by the > hypervisor gives the hypervisor more flexibility than having > the code statically compiled into the kernel. Consider when > hardware virtualization becomes more prevalent. Perhaps > there are places where today hypercalls make sense, but with > hardware virtualization, you'd rather have the hardware just > take care of it. CPUID is the only example I can come up > with at the moment, but there are certainly others. VMI lets > the hypervisor decide that it doesn't actually need to > replace the CPUID instruction with a hypercall. The > important factor here is that only the hypervisor, not the > kernel, knows about these performance tradeoffs. Very obvious other candidates are the shadowed system state registers (cli, sti, CRx) provided by VT and the shadow page-table support as defined by Pacifica. In particular since these features are dependent on the specific processor revision a hard-coded binary interface doesn't do any good. The ROM pretty much resembles Linux' system call interface as provided today optimizing for the specific HW architecture. - Volkmar
