Weekly Edition
Return to the Kernel page
| |||||||||||||
The VMI virtualization interface
Nobody could ever claim that there is a shortage of Linux virtualization
technologies to choose from. There are numerous approaches, from
lightweight "container" techniques which simply create walls between parts
of the system, to full virtualization approaches which implement a complete
virtual hardware platform capable of running a number of (unmodified)
operating systems. Between the two are "paravirtualization" approaches
which require a certain amount of awareness in the guest kernel. To many,
paravirtualization seems like the best approach, in that it promises to
combine a relatively high level of performance with strong isolation of
guest systems. Xen is currently the highest-profile paravirtualization
system out there, but there are others.
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:
VMI Linux has negligible overheads on native machines, so much so,
that we are confident that VMI Linux can, in the long run, be the
default Linux for i386.
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. (Log in to post comments)
The VMI virtualization interface Posted Mar 16, 2006 18:11 UTC (Thu) by iabervon (subscriber, #722) [Link] Would it be possible to reorganize UML as a VMI ROM, such that it actually runs a regular kernel, catches the request for the ROM (which the regular kernel isn't expecting to provide), return the UML routines, and have it work essentially the same as the current design.
I suspect that it would be really helpful for debugging if you could run an unmodified kernel binary as a UML kernel.
The VMI virtualization interface Posted Mar 16, 2006 23:53 UTC (Thu) by aliguori (guest, #30636) [Link] Yup. You need kernel support because you'll want to run the kernel in ring 1 which is normally not accessible to userspace.
It may be more natural to use something like Qemu as a base though since it already supports all of the platform hardware emulation.
The VMI virtualization interface Posted Mar 17, 2006 6:20 UTC (Fri) by xoddam (subscriber, #2322) [Link] > It may be more natural to use something like Qemu as a base though > since it already supports all of the platform hardware emulation. If you're talking about running an unmodified Linux kernel inside a userspace emulator, surely Qemu can do that already -- no UML required? Would the VMI make it any easier to do so?
The VMI virtualization interface Posted Mar 17, 2006 6:21 UTC (Fri) by xoddam (subscriber, #2322) [Link] My comment did *not* look like that in preview ... strange.
Can UML use VMI? Posted Mar 17, 2006 5:26 UTC (Fri) by xoddam (subscriber, #2322) [Link] > Would it be possible to reorganize UML as a VMI ROM, such that it> actually runs a regular kernel, With a solid VMI interface you should be able to run a 'regular' kernel (that uses VMI) in userspace with the right 'thunking' layer, yes. > ... and have it work essentially the same as the current design. It would have to be much simpler than the current design, because the 'regular kernel' would expect to manage its processes' VM which would have to be done entirely in software (and incur a big performance penalty). I believe the current UML implementation has a (seriously complicated) mapping of the UML kernel's processes onto host kernel processes, for VM performance reasons. Xen and VMWare don't have this problem because unlike UML's host Linux kernel, they are set up with the clients' VM in mind and are able to give out portions of physical memory to be managed by each client through a lightweight indirection of the low-level registers. A more likely scenario is that UML continues to use a heavily modified child kernel. Whether it uses a 'VMI ROM' underneath makes little difference (just moves bits of the patch around).
The VMI virtualization interface Posted Mar 24, 2006 5:41 UTC (Fri) by zamsden (guest, #36686) [Link] Yes and no. It could be done - with lots of effort. UML requires running the kernel at CPL-3, whichis something not currently supported in the VMI interface. There are many other aspects, tied to device emulation, that really are not appropriate in the UML world. And UML has more complications due to the process address space model.
That said, I think UML serves a very different purpose than VMI, although they could probably be
|
|||||||||||||