Avi Kivity wrote: > On 07/05/2010 03:16 PM, Jan Kiszka wrote: >>> It's also architecturally cleaner. Masks and acks are architectural >>> events. Injections are not - there's the edge on the LINT0 or INTI2 >>> pins, generation of an APIC message, receipt of the APIC message, and >>> assertion of the APIC-to-core interrupt interface. I'm not sure how the >>> proposed interface maps to that. >>> >> Our emulation does not reflect every architectural detail of the >> delivery path anyway. > > Usually, when that happens, we get an obscure bug. > > So if we add a facility, especially across the user/kernel boundary, > it's better to have it conform to the architecture. That reduces the > chance it has a serious hidden bug.
Neither ack/mask notifiers (past the IRQ controller) nor injection return values are part of any architecture we emulate. What is driving us are the requirements of the de-coalescing workarounds we want to build on top and the impact on existing design. > >> The abstraction is always an IRQ line which can be >> high or low (sometimes it is only high, but this is a bug). >> > > That's a bug in the use of qemu_irq, not qemu_irq itself. > > But qemu_irq needs to remember its state, otherwise when an irq > controller unmasks a level-triggered line, it won't see the interrupt. I think it's currently the IRQ controller's job to keep track of the line state during masked periods. Moving this to qemu_irq is definitely better but requires some care (e.g. when vmstates are involved). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux