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
