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: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] Re: APIC rework
From: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Date: Wed, 18 Nov 2009 11:25:22 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Han, Weidong" <weidong.han@xxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Tue, 17 Nov 2009 19:25:52 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C728AEDA.C2EA%keir.fraser@xxxxxxxxxxxxx>
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: <706158FABBBA044BAD4FE898A02E4BC201CD32062E@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C728AEDA.C2EA%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcpnRahRKdY8JG4aRBKJtSOrmCF95gAPb6tAAADLjVUAAFOzQAANzk5eAA9qNnA=
Thread-topic: [Xen-devel] Re: APIC rework
Keir Fraser wrote:
> Xiantao,
> Responding inline below with stupid/basic questions. Just want to go
> back to first principles with this and work out which of us is on the
> wrong track. 
> On 17/11/2009 14:17, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx> wrote:
>> Originally, this patch is target to get rid of ioapic changes in
>> dom0. Before this patch, GSI irq should be mapped and setup through
>> dom0 programming ioapic entries, but it depends on using ioapic
>> logic in dom0. 
> So dom0 doesn't write the IOAPIC *at all*? Okay.

Dom0 won't write ioapic in new dom0, and all operations related to ioapic 
should be dummy, won't trap to hypervisor any more. 

>> And if we remove ioapic
>> logic from dom0,  we need to find new way how to setup GSI irq.  And
>> this patch comes out under this situation.
> Why does this need to be done under dom0 control? All GSIs are
> parseable by Xen by itself aren't they, from MPBIOS tables or ACPI
> MADT? So at least Xen should be able to work out for itself APIC pin
> -> GSI mappings, and pol/trig settings.

I agree with you at this point, and Xen should has the ability to parse the 
info, but current Xen should doesn't have.
A clean way is to do this in hyervisor and dom0 only ask the request about GSI 
IRQ, like MSI does today. 

>> The idea is from that in Xen the
>> interface MAP_PIRQ_TYPE_MSI is used to build the pirq and irq
>> mapping for MSI IRQ for each domain. Since MSI IRQ can be setup
>> through this hypercall, and I think  we also can leverage the
>> interface MAP_PIRQ_TYPE _GSI to build the mapping for GSI irq.
> For modern dom0 don't we already assume that dom0 pirq == irq == gsi
> (see comments in ioapic_guest_write)? Perhaps we should just have that
> relationship set up by default: I think only NetBSD dom0 has
> different, and it will establish different relationship via legacy
> method of PHYSDEVOP_alloc_irq_vector and paravirtualised IOAPIC
> writes?

The assumption should be right for dom0 today, but it still needs to register 
this info to dom0's private data(d->arch.{pirq_irq, irq_pirq).
And I think maybe we should clean up the logic and let hypervisor knows the 
assumption, when consulting this relationship.


Xen-devel mailing list

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