Re: [RFC, PATCH 5/24] i386 Vmi code patching

[Daniel Arai <arai@vmware.com>]

Zachary Amsden wrote:
> Chris Wright wrote:
>
> > Strongly agreed.  The strict ABI requirements put forth here are not
> > in-line with Linux, IMO.  I think source compatibility is the limit of
> > reasonable, and any ROM code be in-tree if something like this were to
> > be viable upstream.
>
> 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.

If the ROM part is compiled into the code, then you have to compile in support 
for the specific hypervisor(s) you want to run on.  It might be reasonable for 
this code to be in a lodable kernel module, rather than a device ROM per se, but 
you still want that kernel module to be provided by the hypervisor.

Suppose someone implements a ROM layer for UML, or QEMU, or even for Microsoft's 
hypervisor.  Having the ROM published by the hypervisor now lets you run your 
kernel on that new hypervisor without recompiling.  While this might not be much 
of a benefit for an individual developer who downloads and compiles his own 
kernel, this is a huge win for people who distribute binary kernels, or large IT 
organizations that may have large heterogenous virtual machine farms to maintain.

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.  Or 
maybe in the next version of Xen, it's possible to use sysenter rather than an 
interrupt instruction to do hypercalls.  If the hypervisor publishes this code, 
even older kernels can transparently take advantage of faster ways of doing 
certain things.

Dan.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/