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

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

To: Zachary Amsden <zach@xxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching
From: Daniel Arai <arai@xxxxxxxxxx>
Date: Wed, 22 Mar 2006 14:33:45 -0800
Cc: Andrew Morton <akpm@xxxxxxxx>, Christopher Li <chrisl@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Pratap Subrahmanyam <pratap@xxxxxxxxxx>, Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxx>, Joshua LeVasseur <jtl@xxxxxxxxxx>, Dan Hecht <dhecht@xxxxxxxxxx>, Andi Kleen <ak@xxxxxxx>, Jack Lo <jlo@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx, Linus Torvalds <torvalds@xxxxxxxx>, Anne Holler <anne@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Jyothy Reddy <jreddy@xxxxxxxxxx>, Kip Macy <kmacy@xxxxxxxxxxx>, Ky Srinivasan <ksrinivasan@xxxxxxxxxx>, Leendert van Doorn <leendert@xxxxxxxxxxxxxx>
Delivery-date: Thu, 23 Mar 2006 17:55:50 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4421CCA8.4080702@xxxxxxxxxx>
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> <4421CCA8.4080702@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
Zachary Amsden wrote:
Chris Wright wrote:

Strongly agreed.  The strict ABI requirements put forth here are not
in-line with Linux, IMO.  I think source compatibility is the limit of
reasonable, and any ROM code be in-tree if something like this were to
be viable upstream.

The idea of in-tree ROM code doesn't make sense. The entire point of this layer of code is that it is modular, and specific to the hypervisor, not the kernel. Once you lift the shroud and combine the two layers, you have lost all of the benefit that it was supposed to provide.

To elaborate a bit more, the "ROM" layer is "published" by the hypervisor. This layer of abstraction will let you take a VMI-compiled kernel and run it efficiently on any hypervisor that exports a VMI interface - even one that you didn't know about (or didn't exist) when you compiled your kernel.

If the ROM part is compiled into the code, then you have to compile in support for the specific hypervisor(s) you want to run on. It might be reasonable for this code to be in a lodable kernel module, rather than a device ROM per se, but you still want that kernel module to be provided by the hypervisor.

Suppose someone implements a ROM layer for UML, or QEMU, or even for Microsoft's hypervisor. Having the ROM published by the hypervisor now lets you run your kernel on that new hypervisor without recompiling. While this might not be much of a benefit for an individual developer who downloads and compiles his own kernel, this is a huge win for people who distribute binary kernels, or large IT organizations that may have large heterogenous virtual machine farms to maintain.

Going forward, having the ROM layer published by the hypervisor gives the hypervisor more flexibility than having the code statically compiled into the kernel. Consider when hardware virtualization becomes more prevalent. Perhaps there are places where today hypercalls make sense, but with hardware virtualization, you'd rather have the hardware just take care of it. CPUID is the only example I can come up with at the moment, but there are certainly others. VMI lets the hypervisor decide that it doesn't actually need to replace the CPUID instruction with a hypercall. The important factor here is that only the hypervisor, not the kernel, knows about these performance tradeoffs. Or maybe in the next version of Xen, it's possible to use sysenter rather than an interrupt instruction to do hypercalls. If the hypervisor publishes this code, even older kernels can transparently take advantage of faster ways of doing certain things.

Dan.


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

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