Re: xen interrupt system

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

On Monday 24 August 2009 12:15:52 Manuel Bouyer wrote:
> On Mon, Aug 24, 2009 at 11:35:04AM +0200, Christoph Egger wrote:
> > > 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
>
> This is a pure software construct, isn't it ?

Yes, it is on BIOS/ACPI level.

> If we want to use the same numbers as Xen, we need to know in which order
> Xen probed the ioapics; I'm not sure we can easily get this information.

IOAPICs are enumerated in the MADT ACPI table. The IOAPIC structure has
an gsi_base entry which is the offset added to the pin number. This forms 
the "GSI space".
Xen probes the ioapics this way.

> > > > 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.
>
> And if we don't use ACPI ? I have systems where it's not useable.

a) Update your BIOS to latest version.

b) Not sure how many such systems would have more than one IOAPIC. If there's
only one IOAPIC then it's easy as its gsi_base will be zero.

> I guess we have something similar in the MPBIOS ?
> I think we have the GSI in pic_vecbase in NetBSD, but I suspect it's
> set to -1 when using MPBIOS (from reading the sources).

The issue of no ACPI is hardly a practical one these days, as there aren't
really any system made in the last 10+ years with no ACPI.

>
> Now back to the original question, what does PHYSDEVOP_ASSIGN_VECTOR
> expects as input ?

According to Intel, it always expected the GSI number.
Xen's new interrupt system is able to get the GSI number out of
the ioapics pin, so the discussion is heading to make this hypercall
a nop.

Christoph