Re: [Xen-devel] Re: APIC rework

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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.

> 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.

> 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?

> Further analysis showes that this interface is only used
> for assigning devices to HVM domain in qemu, and I think it should be Okay for
> dom0 building the mapping between its pirq and irq. One different thing for
> GSI irq is that more info should be provided in the call, since GSI IRQ has
> different trigger-mode and polarity (originally it is provided by ioapic write
> in dom0). Certainly, I also think we need to document the related info, and if
> you agree to the change, I am happy to add it.

Maybe this follows if my above assumptions/arguments are broken.

 -- Keir



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