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.
