Re: xen interrupt system

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

On Tuesday 25 August 2009 20:39:32 Manuel Bouyer wrote:
> On Tue, Aug 25, 2009 at 02:34:11PM +0200, Christoph Egger wrote:
> > > > > 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.
>
> I have the 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.
>
> The Dell PE1850 have several ioapics for example.
>
> > > 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.
>
> The PE1850 isn't 10 years old, and yet it has its issues with acpi.
>
> > > Now back to the original question, what does PHYSDEVOP_ASSIGN_VECTOR
> > > expects as input ?
> >
> > According to Intel, it always expected the GSI number.
>
> Experimentally, it was accepting any number, unless it was a
> number already allocated (and some were allocated at boot).
> Maybe we can change it to try to use the GSI number when it exists,
> hopefully we'll reuse the same number as Xen already used for this pin
> and things would work for older hypervisors too.

Intel gave me a patch to test. It makes PHYSDEVOP_allocate_irq_vector
a noop and makes Xen to allocate the irq "on demand" when writing
an ioapic rte. This makes the hypercall succeed in general and NetBSD
wants to bind the irq number 200 to an event channel. The EVTCHN_bind_pirq
fails with EINVAL. This in turn leads to this panic below.

XenSource points out, EVTCHN_bind_pirq expects pirq number
within the GSI space. On the test machine, this GSI space goes from 0 to 47.


panic: Failed to bind physical IRQ 200

fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip ffffffff8020aa8d cs e030 rflags 246 cr2  0 cpl 8 rsp 
ffffffff80f009e0
Stopped in pid 0.1 (system) at  netbsd:breakpoint+0x5:  leave
breakpoint() at netbsd:breakpoint+0x5
panic() at netbsd:panic+0x285
bind_pirq_to_evtch() at netbsd:bind_pirq_to_evtch+0xb7
xen_intr_map() at netbsd:xen_intr_map+0xf2
intr_establish() at netbsd:intr_establish+0x60
acpi_md_OsInstallInterruptHandler() at 
netbsd:acpi_md_OsInstallInterruptHandler+
0x71
AcpiOsInstallInterruptHandler() at netbsd:AcpiOsInstallInterruptHandler+0x78
AcpiEvInstallXruptHandlers() at netbsd:AcpiEvInstallXruptHandlers+0xe
acpi_attach() at netbsd:acpi_attach+0x120
config_attach_loc() at netbsd:config_attach_loc+0x173
hypervisor_attach() at netbsd:hypervisor_attach+0x21b
config_attach_loc() at netbsd:config_attach_loc+0x173
mainbus_attach() at netbsd:mainbus_attach+0xc1
config_attach_loc() at netbsd:config_attach_loc+0x173
cpu_configure() at netbsd:cpu_configure+0x25
main() at netbsd:main+0x1aa