[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] another regression from IRQ handling changes
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |