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/
Home Products Support Community News


[Xen-devel] Re: A proposal - binary

To: Zachary Amsden <zach@xxxxxxxxxx>
Subject: [Xen-devel] Re: A proposal - binary
From: Andi Kleen <ak@xxxxxxx>
Date: Sat, 5 Aug 2006 00:52:36 +0200
Cc: Andrew Morton <akpm@xxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Jack Lo <jlo@xxxxxxxxxx>, Greg KH <greg@xxxxxxxxx>, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx, Linus Torvalds <torvalds@xxxxxxxx>, James.Bottomley@xxxxxxxxxxxx, pazke@xxxxxxxxx
Delivery-date: Fri, 04 Aug 2006 15:53:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44D3CCA1.1040503@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: <44D1CC7D.4010600@xxxxxxxxxx> <200608050001.52535.ak@xxxxxxx> <44D3CCA1.1040503@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.3
> For privileged domains that have hardware privileges and need to send 
> IPIs or something it might make sense. 

Any SMP guest needs IPI support of some sort.

But it is hopefully independent of subarchitectures in the paravirtualized

> doesn't stop Linux from using the provided primitives in any way is 
> sees fit.  So it doesn't top evolution in that sense.  What it does stop 
> is having the Linux hypervisor interface grow antlers and have new 
> hooves grafted onto it.  What it sorely needed in the interface is a way 
> to probe 

That's the direction the interface is evolving I think (see multiple
entry point discussion) 

> and detect optional features that allow it to grow independent 
> of one particular hypervisor vendor.

Ok maybe not with options and subsets so far, but one has to
start somewhere.


Xen-devel mailing list