Re: xen interrupt system

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Fri, Aug 28, 2009 at 02:55:02PM +0200, Christoph Egger wrote:
> 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.

Yes, of course.

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

This is what changed. With previous version EVTCHN_bind_pirq woud accept
any IRQ number, as long as it was unused. We need to rework this part.
The question is 1) if we can guess the corret GSI in all cases (I'm not
sure) 2) if this will work with pre-3.4 hypervisors.

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           
Manuel.Bouyer%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--