Re: xen interrupt system

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

On Monday 24 August 2009 11:12:34 Manuel Bouyer wrote:
> On Mon, Aug 24, 2009 at 08:53:10AM +0200, Christoph Egger wrote:
> > > > So I suppose the question is -- where is NetBSD dom0 conjuring vector
> > > > numbers from? You're going to have to track down the source of that
> > > > 'vector' 0x5e in the NetBSD kernel I think."
> > >
> > > 0x5e is what is returned from PHYSDEVOP_ASSIGN_VECTOR. See
> > > xen_intr_map().
> >
> > PHYSDEVOP_ASSIGN_VECTOR is the old name for PHYSDEVOP_alloc_irq_vector.
> >
> > XenSource wonders if there's some confusion between what Linux vs. NetBSD
> > vs. Xen thinks of as an 'irq number'.
> > I think, for linux dom0, irq number should mean gsi.
>
> what is "gsi" ?

GSI is short for "Global System Interrupt". 

This is needed to form a unique identifier to deal with multiple ioapics.

xen boot message from a machine with three ioapics each with 16 pins.

(XEN) IOAPIC[0]: apic_id 8, version 17, address 0xfec00000, GSI 0-15
(XEN) IOAPIC[1]: apic_id 9, version 17, address 0xfec01000, GSI 16-31
(XEN) IOAPIC[2]: apic_id 10, version 17, address 0xfec02000, GSI 32-47


>
> > Xen also thinks of gsi
> > as irq number, but Xen thinks gsi is contiguous in system and doesn't
> > support sparse gsi before #Cset20076.
> >
> > XenSource & Intel want to know the means of 'irq number' in NetBSD.
>
> Nothing. It's an arbitrary number allocated top-down starting at 200
> (choosen empirically after trial and error to see what range the hypervisor
> would accept), it exists only because PHYSDEVOP_ASSIGN_VECTOR wants one.
> What NetBSD cares about is the tuple (ioapic, pin number, vector)
>
> > XenSource also states:
> >
> > "Firstly, make the irq input to PHYSDEVOP_alloc_irq_vector a different
> > namespace to the GSI space.
>
> How do we know the "GSI space" ?

From the MADT ACPI table, IO Apic structure byte offset 8.

>
> > I don't know whether these days we really
> > require GSIs to be specified at this interface? Do the numbers really
> > need to mean much beyond an identifier which is later written to an
> > IOAPIC pin?
>
> For NetBSD, no. But what needs to be written to the IOAPIC pin ?
> The value we passed to PHYSDEVOP_alloc_irq_vector, or the value returned
> by PHYSDEVOP_alloc_irq_vector ? I guess the later, as it's what's working
> now, with hypervisors up to 3.3
>
> > After all, that would make the whole hypercall pretty pointless, since
> > the GSI is also uniquely identified by the IOAPIC pin we are later
> > writing to!
> >
> > Alternatively, if we really do require GSIs to be specified at this
> > hypercall interface, this could be a regrettable interface break for
> > NetBSD."
> >
> > > > XenSource thinks that the vector 0x5e is wrong because according
> > > > to this xen boot messages, the vectors go from 0 - 47.
> > >
> > > AFAIK we can use any vector number in the range 0xff - 0xff in the
> > > ioapic registers.  I guess this is a rectriction imposed by Xen.
> >
> > You mean range 0x00 - 0xff, I suppose.
>
> Yes of course.