| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] another regression from IRQ handling changes
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).
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.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home