>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 22.09.09 11:14 >>>
>On 22/09/2009 09:53, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>
>>> If it wasn't broken before, it was probably broken by Xiantao's follow-up
>>> patch to fix NetBSD dom0 (at least as much as possible, to avoid a nasty
>>> regression with NetBSD). What we probably need to do is have a 256-entry
>>> dom0_vector_to_dom0_irq[] array, and allocate an entry from that for every
>>> fresh irq we see at PHYSDEVOP_alloc_irq_vector. Then when the vector gets
>>> passed back in on ioapic writes, we index into that array rather than using
>>> naked rte.vector.
>>
>> Yeah, that's what I would view as the solution to get old functionality
>> back. But my question also extended to possible solutions to get beyond
>> 256 here, especially such that are also acceptable to the pv-ops Dom0,
>> which I'm much less certain about.
>
>Well, we could assume that if we see an irq greater than 256 at
>PHYSDEVOP_alloc_irq_vector then the dom0 is dealing in GSIs, and in that
>case the 'vector' we return and then gets passed to ioapic_write is rather
>redundant. We can work out the GSI from the ioapic rte that is being
>modified, after all. So perhaps we could just flip into a non-legacy mode of
>operation in that case (perhaps reserve a single magic 'vector' value to
>return from PHYSDEVOP_alloc_irq_vector in this case, and if we see that
>value in the ioapic write handler then we know to assume that guest pirq ==
>gsi).
I wouldn't base this on the passed in IRQ number, but instead on the
number of IRQs mapped - if the proposed array doesn't have a spare
slot anymore, switch to passing back the magic vector (and assume
pirq == irq in ioapic_guest_write() - we could even add checking of
that for all previously enabled IRQs this relation is true, and fail
PHYSDEVOP_alloc_irq_vector if the array got exhausted and Dom0
didn't use only GSIs before). But besides that detail your idea sounds
fine at least from a Linux perspective.
Are you planning on getting this done, or should I?
>The legacy case is just to handle NetBSD, which throws non-GSIs at the
>PHYSDEVOP_alloc_irq_vector interface, and I doubt it will have worked with
>those mega-big systems at any time. So I don't think we're dealing with a
>regression there.
Hmm, no, the regression is with (newer?) Linux, which should have been
capable of dealing with interrupts coming in on IO-APIC pins above 256
before that change.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home