Re: xen interrupt system

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

On Mon, Aug 31, 2009 at 10:52:43AM +0200, Christoph Egger wrote:
> 
> Intel sent me a new patch to test which maps the value passed 
> PHYSDEVOP_alloc_irq_vector with EVTCHN_bind_pirq internally, so that the
> value passed to EVTCHN_bind_pirq is "recognized" by Xen when it allocates
> the real interrupt "on demand" on IOAPIC writes.
> 
> Now this makes the NetBSD dom0 fail to boot in a different way:
> Our way to initialize ioapics fails.
> 
> ioapic0 at mainbus0 apid 8, virtual wire mode
> (XEN) io_apic.c:2196: 
> (XEN) ioapic_guest_write: apic=0, pin=0, irq=0
> (XEN) ioapic_guest_write: new_entry=00010900
> (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
> (XEN) io_apic.c:2196: 
> (XEN) ioapic_guest_write: apic=0, pin=2, irq=0
> (XEN) ioapic_guest_write: new_entry=00010900
> (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
> (XEN) irq.c:1297: dom0: pirq 0 or irq 3 already mapped

This is when we clear the ioapic. It used to fail before too, but it
was not fatal. E.g. with xen 3.1.4:
(XEN) io_apic.c:2135: 
(XEN) ioapic_guest_write: apic=0, pin=2, old_irq=0, new_irq=-1
(XEN) ioapic_guest_write: old_entry=000009f0, new_entry=00010900
(XEN) ioapic_guest_write: Attempt to remove IO-APIC pin of in-use IRQ!
(XEN) io_apic.c:2135: 
(XEN) ioapic_guest_write: apic=0, pin=4, old_irq=4, new_irq=-1
(XEN) ioapic_guest_write: old_entry=000009f1, new_entry=00010900
(XEN) ioapic_guest_write: Attempt to remove IO-APIC pin of in-use IRQ!


> PHYSDEVOP_APIC_WRITE ret -22
> panic: PHYSDEVOP_APIC_WRITE

we could change the prototype of ioapic_write_ul to return an error
number instead of void, and let the caller handle the error (n ioapic_attach
we would just ignore the error). the native ioapic_write_ul would always
return 0 of course.

> 
> Intel and XenSource also stated:
> 
> Intel:
> "For MSI, we need to solve the pirq conflict issue, since the irq passed by
> PHYSDEVOP_alloc_irq_vector is recognized as pirq number in the
> EVTCHN_bind_pirq."
> 
> XenSource (in response to Intel's statement):
> "My guess is that NetBSD does not have support for MSI on Xen so that's a
> non-issue. And Linux provides GSI to alloc_irq_vector and to bind_pirq (when
> setting up legacy INTx irqs) so obviously avoids the possible conflict. If
> NetBSD supports MSI-on-Xen in future, it will have to clean up its act
> regarding the irq numbers it hands to the abovementioned hypercalls. That's
> a reasonable constraint though."

We don't support MSI for now, even in native mode.

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