WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching
From: Eli Collins <ecollins@xxxxxxxxxx>
Date: Thu, 23 Mar 2006 15:45:54 -0800
Cc: Christopher Li <chrisl@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx, Linus Torvalds <torvalds@xxxxxxxx>, Kip Macy <kmacy@xxxxxxxxxxx>, Jyothy Reddy <jreddy@xxxxxxxxxx>, Anne Holler <anne@xxxxxxxxxx>, Ky Srinivasan <ksrinivasan@xxxxxxxxxx>, Leendert van Doorn <leendert@xxxxxxxxxxxxxx>
Delivery-date: Thu, 23 Mar 2006 23:47:21 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <caf37c433827769063ccb0269adbaa09@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <200603131802.k2DI2nv8005665@xxxxxxxxxxxxxxxxxxx> <200603222115.46926.ak@xxxxxxx> <20060322214025.GJ15997@xxxxxxxxxxxxxxxxxx> <4421EC44.7010500@xxxxxxxxxx> <20060323004006.GQ15997@xxxxxxxxxxxxxxxxxx> <caf37c433827769063ccb0269adbaa09@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5 (X11/20051201)
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

<Prev in Thread] Current Thread [Next in Thread>