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


Re: [Xen-devel] Re: APIC rework

To: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: APIC rework
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Wed, 18 Nov 2009 09:15:22 -0500
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Han, Weidong" <weidong.han@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Wed, 18 Nov 2009 06:17:03 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <706158FABBBA044BAD4FE898A02E4BC201CD3205FF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C727CCCB.C018%keir.fraser@xxxxxxxxxxxxx> <4B023285.50702@xxxxxxxx> <706158FABBBA044BAD4FE898A02E4BC201CD3205FF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.19 (2009-01-05)
On Tue, Nov 17, 2009 at 08:46:19PM +0800, Zhang, Xiantao wrote:
> Jeremy Fitzhardinge wrote:
> > On 11/16/09 19:45, Keir Fraser wrote:
> >> It's kind of a shame to need this though. Is there no way for the
> >> hypervisor to work out automatically whether an older dom0 is
> >> running? Or work out the trigger/level stuff for itself (after all
> >> it parses the relevant bios tables just like dom0)?
> > 
> > If Xen can set the interrupt triggering by itself, why would it ever
> > need dom0 to do it?  Couldn't it just preconfigure all the pins, and
> > then wait for dom0 to provide/request the pirq<->evtchn mapping?
> After reviewing the logic, I think we can use DOMID_SELF to identify new 
> dom0.  In linux-2.6.18 dom0, only qemu uses this hypercall for device 
> assginment, so map->domid shouldn't be dom0.  If old dom0/qemu with this 
> hypercall, keeps the logic unchanged, and only change the logic for new dom0 
> when call into it.   Attached the patch. 

What about privileged domains that are not domain 0? Won't that
mess this up?

Xen-devel mailing list

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