On Sun, Jun 6, 2010 at 7:15 AM, Gleb Natapov <g...@redhat.com> wrote: > On Sat, Jun 05, 2010 at 02:04:01AM +0200, Jan Kiszka wrote: >> > I'd like to also support EOI handling. When the guest clears the >> > interrupt condtion, the EOI callback would be called. This could occur >> > much later than the IRQ delivery time. I'm not sure if we need the >> > result code in that case. >> > >> > If any intermediate device (IOAPIC?) needs to be informed about either >> > delivery or EOI also, it could create a proxy message with its >> > callbacks in place. But we need then a separate opaque field (in >> > addition to payload) to store the original message. >> > >> > struct IRQMsg { >> > DeviceState *src; >> > void (*delivery_cb)(IRQMsg *msg, int result); >> > void (*eoi_cb)(IRQMsg *msg, int result); >> > void *src_opaque; >> > void *payload; >> > }; >> >> Extending the lifetime of IRQMsg objects beyond the delivery call stack >> means qemu_malloc/free for every delivery. I think it takes a _very_ >> appealing reason to justify this. But so far I do not see any use case >> for eio_cb at all. >> > I dislike use of eoi for reinfecting missing interrupts since > it eliminates use of internal PIC/APIC queue of not yet delivered > interrupts. PIC and APIC has internal queue that can handle two elements: > one is delivered, but not yet acked interrupt in isr and another is > pending interrupt in irr. Using eoi callback (or ack notifier as it's > called inside kernel) interrupt will be considered coalesced even if irr > is cleared, but no ack was received for previously delivered interrupt. > But ack notifiers actually has another use: device assignment. There is > a plan to move device assignment from kernel to userspace and for that > ack notifiers will have to be extended to userspace too. If so we can > use them to do irq decoalescing as well. I doubt they should be part > of IRQMsg though. Why not do what kernel does: have globally registered > notifier based on irqchip/pin.
Because translation at IOAPIC may be lossy, IRQs from many devices pointing to the same vector? With IRQMsg you know where a specific message came from. The situation is different inside the kernel: it manages both translation and registration, whereas in QEMU we could only control registration.