Re: xen interrupt system

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

On Friday 21 August 2009 13:40:07 Manuel Bouyer wrote:
> On Fri, Aug 21, 2009 at 01:28:00PM +0200, Christoph Egger wrote:
> > XenSource:
> >
> > "Well, dom0 may think it using a vector but it isn't. Linux-2.6.18 for
> > example is allocating vectors for irqs using
> > PHYSDEVOP_alloc_irq_vector(), as it is supposed to. But crucially after
> > Xiantao's patch it now gets the irq returned back to it. Dom0 then thinks
> > it is poking a vector into the IO-APIC RTE, but Xen knows it is an irq
> > and does the appropriate translation. We can do tricks like this because
> > Xen manages the vector 'namespace' and so can virtualise it as it likes.
>
> OK, so what we write to IOAPIC_REDLO is a virtual vector number that Xen
> calls "irq". Xen then translates this to the real vector number.

Exactly.

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

XenSource also states:

"Firstly, make the irq input to PHYSDEVOP_alloc_irq_vector a different
namespace to the GSI space. 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?
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.

Christoph