On Tue, May 25, 2010 at 9:44 PM, Jan Kiszka <jan.kis...@web.de> wrote: > Anthony Liguori wrote: >> On 05/25/2010 02:09 PM, Blue Swirl wrote: >>> On Mon, May 24, 2010 at 8:13 PM, Jan Kiszka<jan.kis...@web.de> 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. >>>> >>> No real devices are interested whether any of their output lines are >>> even connected. This would introduce a new signal type, bidirectional >>> multi-level, which is not correct. >>> >> >> I don't think it's really an issue of correct, but I wouldn't disagree >> to a suggestion that we ought to introduce a new signal type for this >> type of bidirectional feedback. Maybe it's qemu_coalesced_irq and has a >> similar interface as qemu_irq. > > A separate type would complicate the delivery of the feedback value > across GPIO pins (as Paul requested for the RTC->HPET routing). > >> >>> I think the real solution to coalescing is put the logic inside one >>> device, in this case APIC because it has the information about irq >>> delivery. APIC could monitor incoming RTC irqs for frequency >>> information and whether they get delivered or not. If not, an internal >>> timer is installed which injects the lost irqs. > > That won't fly as the IRQs will already arrive at the APIC with a > sufficiently high jitter. At the bare minimum, you need to tell the > interrupt controller about the fact that a particular IRQ should be > delivered at a specific regular rate. For this, you also need a generic > interface - nothing really "won".
OK, let's simplify: just reinject at next possible chance. No need to monitor or tell anything.
