[Xen-devel] RE: [RFC, PATCH 5/24] i386 Vmi code patching

[Volkmar Uhlig <vuhlig@xxxxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel