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). Moreover, I think that the third return state, QEMU_IRQ_MASKED, is important for correct handling of multiple IRQ sinks. 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. Jan
signature.asc
Description: OpenPGP digital signature