The VMI virtualization interface
Each paravirtualization approach places its own demands on the guest system. Before a particular system can run under a given hypervisor, it must be modified to work with that hypervisor's interface. This requirement can add to the work of creating a virtual system in the first place, and it increases the maintenance burden going forward, especially if both the hypervisor and the guest kernel are under heavy development.
In an attempt to make life easier for virtualization hackers, Zachary Amsden (of VMware) has put forward a complex proposal for a common virtual machine interface (VMI) layer with some interesting properties. The VMI layer defines a set of calls for performing machine-specific functions - the sorts of things that generally require hypervisor intervention. These calls are very low-level - operations like changing page protections, enabling interrupts, writing model-specific registers, changing specific control registers, dealing with timer events, etc. As a result, the VMI interface currently only works with i386-architecture systems, though an x86-64 port is in the works.
When a virtualized kernel boots, one of the first things it does is search for a "VMI ROM" provided by the hypervisor. That ROM provides the information needed for the low-level VMI calls to interact with the hypervisor. Using information found in the ROM, the just-booted kernel modifies its own code to use the hypervisor's functions without table lookups or indirect function calls. As a result, hypervisor operations are fast.
There are a couple of interesting implications of this approach. One is that a VMI-equipped kernel can run under any VMI hypervisor without modification - or even recompilation. It simply grabs the ROM provided by whatever hypervisor is present and gets on with life. Just as interesting is the fact that such a kernel can run on the bare hardware with no hypervisor at all, as the host kernel. The VMI developers state that the performance impact of running with the VMI calls is essentially zero. That leads to this claim:
The actual code is packaged as a 24-part patch. It involves significant
amounts of low-level tweaking and assembly language trickery. That may
have something to do with why there have been few comments on the code
itself. The discussion which has been seen seems somewhat favorable, if
reserved. Among other things, there will need to be an open source
hypervisor which uses this interface before it will be seriously considered
for merging. In the mean time, anybody interested in the details can learn
more from the documentation file.
| Index entries for this article | |
|---|---|
| Kernel | Virtualization |