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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
