On Tue, Jun 1, 2010 at 6:30 PM, Gleb Natapov <g...@redhat.com> wrote: > On Tue, Jun 01, 2010 at 06:00:20PM +0000, Blue Swirl wrote: >> >> > Looks like irr in apic is never cleared. Probably bug in userspace apic >> >> > emulation. I'll look into it. Try to route interrupt via APIC (not >> >> > ExtInt), >> >> > or use qemu-kvm with in kernel irq chip. >> >> >> >> With APIC you mean Fixed? Then the IRQ is not delivered at all. >> > You need to deliver it through IOAPIC. >> >> In this version, when USE_APIC is defined, IRQs are routed via IOAPIC >> and APIC, PIC interrupts are disabled. Otherwise, IOAPIC and APIC are >> left to reset state and PIC is used. >> >> With the PIC version, there are bogus injections. With IOAPIC and APIC >> dots come at 2Hz. -enable-kvm has no effect. > > I looked into this briefly. Virtual wire case is not handled correctly, > and pic lacks coalescing detection at all (the reason BTW because proper > solution was rejected, so only hack required by Windows was added). > Windows routes RTC interrupts through IOAPIC and this case works as you > can see. -enable-kvm on qemu should not make any difference since it > uses the same userspace pic/ioapic/apic code as TCG. It would be > interesting to try with qemu-kvm which uses in-kernel irq chips by > default. > > BTW I managed to compile you test program with gcc 4.2. 4.4 and 4.3 > produced non-working binaries for me.
This exercise showed me that the IRQ connectivity between APIC and RTC can vary a lot because of guest activities. So it may be impossible to know at APIC if some IRQ came from RTC and so the coalescing must be accounted at RTC (or close to RTC). This makes a generic solution less useful, I think the net result would be to refactor rtc_coalesced_timer*() to a new file. Also my generic approach of time base adjustment would need to be steered by RTC because APIC can't. So I think I'll have to abandon this idea for now. Sorry for the delay, thanks for the interesting discussion though. Coming back to $SUBJECT: I don't think the bidirectional IRQ is a good solution either, but it may be slightly better than current hack (I didn't realize the full ugliness of the hack before, namely that APIC and RTC are really not connected at all). The same effect could be achieved with two signals going to opposite directions, like APICREQ/APICACK on 82093 IOAPIC but again, if any IRQs point to same vector at IOAPIC, there is no way to get back to originator. With bidirectional IRQs, there's a one-shot chance at the delivery time, but not later at ACK/EOI time. But how about if we introduced instead a message based IRQ? Then the message could specify the originator device, maybe ACK/coalesce/NACK callbacks and a bigger payload than just 1 bit of level. I think that could achieve the same coalescing effect as what the bidirectional IRQ. The payload could be useful for other purposes, for example Sparc64 IRQ messages contain three 64 bit words.