Blue Swirl wrote: > 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.
If there are more users than just IRQ de-coalescing, this indeed sounds superior. We could pass objects like this one around: struct qemu_irq_msg { void (*delivery_cb)(int result); void *payload; }; They would be valid within the scope of the IRQ handlers. Whoever terminates or actually delivers the IRQ would invoke the callback. And platforms like sparc64 could evaluate the additional payload pointer in their irqchips or wherever they need it. IRQ routers on platforms that make use of these messages would have to replicate them when forwarding an event. OK? Jan
signature.asc
Description: OpenPGP digital signature