Re: xen interrupt system

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

On Mon, Aug 24, 2009 at 08:53:10AM +0200, Christoph Egger wrote:
> > > 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.

what is "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.

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" ?

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

For NetBSD, no. But what needs to be written to the IOAPIC pin ?
The value we passed to PHYSDEVOP_alloc_irq_vector, or the value returned
by PHYSDEVOP_alloc_irq_vector ? I guess the later, as it's what's working now,
with hypervisors up to 3.3

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

Yes of course.

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