Gleb Natapov wrote: > On Tue, May 25, 2010 at 08:31:06AM +0200, Jan Kiszka wrote: >> Gleb Natapov wrote: >>> On Mon, May 24, 2010 at 10:13:40PM +0200, Jan Kiszka wrote: >>>> From: Jan Kiszka <jan.kis...@siemens.com> >>>> >>>> This allows to communicate potential IRQ coalescing during delivery from >>>> the sink back to the source. Targets that support IRQ coalescing >>>> workarounds need to register handlers that return the appropriate >>>> QEMU_IRQ_* code, and they have to propergate the code across all IRQ >>>> redirections. If the IRQ source receives a QEMU_IRQ_COALESCED, it can >>>> apply its workaround. If multiple sinks exist, the source may only >>>> consider an IRQ coalesced if all other sinks either report >>>> QEMU_IRQ_COALESCED as well or QEMU_IRQ_MASKED. >>>> >>> Well, almost two years passed since this approach was proposed first >>> time[1] ;). Back then it generated bunch of nonsensical comments about >>> real hardware not working this way, so the hack that we have now was >>> introduce to overcome this resistance. I hope enough time passed for >>> people to gain some sense and the approach will be adopted this time. >>> Really this should have been done two year ago. >>> >>> [1] http://lists.nongnu.org/archive/html/qemu-devel/2008-06/msg00757.html >> Yeah, I somehow had a vague feeling that there must have been an earlier >> attempt. I think my approach could be a slightly easier to accept as it >> does not require converting all platforms, but this can happen on demand >> (or not at all). > I proposed that too at some point (to lazy to look for it in archives > and it was in words not patch). But since resistance to that approach > from the beginning was baseless no sane arguments or compromises would > help at that point. > >> Moreover, I think that the third return state, >> QEMU_IRQ_MASKED, is important for correct handling of multiple IRQ sinks. > My patch had that too: <0 = coalesced, 0 = masked, >0=delivered
Oh, indeed! Good to see that we came up with the same logic. > >> However, as I would see it now, we just have two options long term: >> - drop IRQ coalescing workarounds >> - properly support them via qemu_irq >> >> The current hack cannot stay. E.g., it does not scale because it depends >> on a global variable of the APIC. So we would never able to protect the >> APICs with individual locks. >> > Agree, and that was well understood at the time the hack was introduced. > But we can't just drop RTC IRQ reinjectoin. It would be crippling of qemu. > So we have only _one_ option: > - properly support them via qemu_irq You won't hear me disagreeing. Jan
signature.asc
Description: OpenPGP digital signature
