On Sat, Jun 12, 2010 at 2:15 PM, Paul Brook <p...@codesourcery.com> wrote: >> On Sat, Jun 12, 2010 at 12:21 PM, Paul Brook <p...@codesourcery.com> wrote: >> >> This patch allows to optionally attach a message to an IRQ event. The >> >> message can contain a payload reference and a callback that the IRQ >> >> handler may invoke to report the delivery result. The former can be used >> >> to model message signaling interrupts, the latter to cleanly implement >> >> IRQ de-coalescing logics. >> > >> > I don't like this. qemu_irq is a level triggered interface. Redundant >> > calls to qemu_set_irq should (in principle) be a no-op. If you want >> > message passing then IMO you should be using something else. >> >> Keeping the optional message and qemu_irq together means that we can >> reuse the existing IRQ subsystem. I'd guess something more separated >> would need duplicate allocation and delivery support and maybe even >> SysBus etc. would need lots of work to support a new class of IRQs. > > How do you propose message passing is handled when you have nested multi-layer > interrupt trees?
Do we have such trees somewhere? I think message passing interrupts are only used in bus based systems, like PCI or UPA/JBUS etc. I don't know how LAPIC/IOAPIC bus works, it could be similar. > How long is the message data valid for? Currently it's valid for the duration of the call. It may make sense to extend that later in order to handle EOIs. > Who owns it? The source. > How is a > receiver meant to know for format of the message being delivered, and who it's > intended for? This depends on the architecture. On Sparc64 the message is specified by the guest or OF. > IMO message triggered systems are fundamentally different to level states. > qemu_irq represents a level state, and I'd really like for it to stay that > way. In real HW (MSI or Sparc64 mondo interrupts) a bus delivers the message. But our buses only handle address and data lines. > If we need/want a generic message passing interface, then that's a different > problem, and needs to be done in such a way that the devices always agree on > the type of message being passed. > > TBH I preferred the original system whereby the source can query the state of > the sink (i.e "are you ignoring this line?"). Note that conceptually this > should be *querying* state, not responding to an event. It's simple, but I think too simple. It would work for the coalescing interrupt hack but useless for other things.