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

[Eli Collins <ecollins@xxxxxxxxxx>]

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