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 4/24] i386 Vmi inline implementation

To: Pavel Machek <pavel@xxxxxx>
Subject: [Xen-devel] Re: [RFC, PATCH 4/24] i386 Vmi inline implementation
From: Zachary Amsden <zach@xxxxxxxxxx>
Date: Wed, 15 Mar 2006 15:56:53 -0800
Cc: Andrew Morton <akpm@xxxxxxxx>, Joshua LeVasseur <jtl@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Pratap Subrahmanyam <pratap@xxxxxxxxxx>, Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxx>, Jack Lo <jlo@xxxxxxxxxx>, Dan Hecht <dhecht@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Christopher Li <chrisl@xxxxxxxxxx>, Virtualization Mailing List <virtualization@xxxxxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxx>, Anne Holler <anne@xxxxxxxxxx>, Jyothy Reddy <jreddy@xxxxxxxxxx>, Kip Macy <kmacy@xxxxxxxxxxx>, Ky Srinivasan <ksrinivasan@xxxxxxxxxx>, Leendert van Doorn <leendert@xxxxxxxxxxxxxx>, Dan Arai <arai@xxxxxxxxxx>
Delivery-date: Fri, 17 Mar 2006 10:42:31 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20060315225212.GB1719@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.k2DI22OK005657@xxxxxxxxxxxxxxxxxxx> <20060315225212.GB1719@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5 (X11/20051201)
Pavel Machek wrote:
We already do runtime patching for SMP vs. UP, could you use same
infrastructure? I do not want VMI-specific grub.

I think we could almost use the same infrastructure - or extend it to work. The problem is how to determine register liveness for calls into the VMI layer which take > 3 arguments. If you squeeze all the arguments into fixed registers, you can unnecessarily constrain the native code - and rapidly run out of registers for the compiler to use, generating impossible constraints in some cases.

To work around these issues, we do not constrain the arguments beyond the first three registers. But this means that the hypervisor needs a way to locate the additional arguments. That information gets encoded implicitly by the auto-generated translation into a VMI call, which pushes the arguments onto the stack (thus revealing the registers, and allowing constant immediate optimization).

Now, if you can generate all of the code to do the callout to the VMI, you could use it directly in an alternative instruction sequence, just as the existing infrastructure. But I'm not sure you can do it in one compiler pass. We are already pushing the limits of the preprocessor, compiler and assembler here. Having another preprocessing pass may make it possible, but it does make the build more complicated.

I'm not sure it is really what we want though. The alternative instruction interfaces is based on global feature detection that is done and applied by the _kernel_. In the end, we want the hypervisor to be able to toggle each VMI call site as a separate feature, and replace it with hypervisor specific code. In this way, a VT based hypervisor could simply not patch those class of VMI calls that are already emulated by hardware, and also inline direct hypercalls for those classes that are not. The VMI layer is supposed to be very much an inline linker for feature detection done by the _hypervisor_.

Zach

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