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: Zachary Amsden <zach@xxxxxxxxxx>
Date: Thu, 23 Mar 2006 10:50:58 -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 18:52:23 +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:

Yeah, point is the interface is normal C API, and has the similar free
form that normal kernel API's have.

i think this sounds very sane, and an OS-specific interface shim gets around problems such as finding CPU-specific state -- we can get at smp_processor_id() just the same as the rest of the kernel, for example. 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.

Getting at smp_processor_id() is exactly the type of thing you _don't_ want to do. You really can't have callbacks into the guest in the hypervisor platform layer. It really is not efficient, and you cause yourself more trouble than it is worth.

And where exactly is smp_processor_id() exported to modules? It's not. You've just locked your module into the current kernel's idea of how to get at smp_processor_id(). It changes based on compilation options of the kernel - for example, it is different with 4K stacks. It has changed from a number of other different options in the past.

The fact that XenoLinux needs smp_processor_id() at all is quite ludicrous. To disable interrupts, which is used fairly commonly to disable pre-emption as well, what does XenoLinux have to do?

It has to disable pre-emption to call smp_processor_id() so that it can disable interrupts, the re-enable preemption so that it can disable pre-emption.

That is truly convoluted, and is exactly why you should never get into these types of situations to begin with.

Zach

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

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