[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Keir Fraser wrote:
We could extend the concept of the interface shim we already have -- a set of OS-specific high performance shims, plus a fallback OS-agnostic shim.

Currently the lack of a shim is the key difference between the VMI and Xen approaches. Forgive me for summarizing, but I'm not sure it's been made clear. The VMI is the interface between the OS and a shim layer--it is not a hypervisor interface. The kernel makes VMI calls to the shim and the shim makes hypercalls, if needed, to the hypervisor.

    VMI                   VMI native            Xen/Xen native


     OS                      OS                     OS
-------------- VMI      -------------- VMI
  Shim (ROM)
-------------- HV API                          -------------- HV API
  Hypervisor              Native HW              Hypervisor


The VMI isolates the kernel from the hypervisor so that the kernel and the hypervisor can evolve w/o hindering each other's development. The Xen approach still tightly couples the hypervisor with the kernel. Coupling the kernel and hypervisor together restricts their evolution and people who want to run different operating systems (or different versions of the same OS) on the same hypervisor. As Josh pointed out, you can run a single VMI Linux kernel on more versions of the Xen hypervisor than you can using a single XenLinux kernel because the VMI does not require a tight coupling.

Tight coupling also means you end up using a hypervisor when running a kernel natively (e.g. "supervisor mode kernel" in the unstable Xen repository). So for the native case you get a level of indirection (the hypervisor) that costs you performance, and for the virtual case you do not get a level of indirection (a shim) that buys you compatibility and diversity. For VMI, it's the reverse, you get the level of indirection in the virtual case and no indirection in the native case. You could have separate kernels, and all the associated costs, for these two cases.

There are many places where the VMI and Xen patches overlap; the key difference is that the VMI makes a distinction between the kernel and the hypervisor interfaces. As others have pointed out this distinction buys you a lot in terms of compatibility, ease of maintenance, and the ability to execute the same kernel in native and virtual environments with high performance.

Which particular bits get in is less important than the decision of whether or not the Linux community wants the kernel tightly coupled to the hypervisor. Extending the hypercall page you already have to decouple the hypervisor and kernel interfaces would be excellent.

Eli

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.