Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs

[Blue Swirl]

On Sun, Jun 13, 2010 at 6:39 PM, Paul Brook <address@hidden> wrote:
>> On Sun, Jun 13, 2010 at 3:49 PM, Paul Brook <address@hidden> wrote:
>> >> I think we could solve all problems (well, maybe not world peace, yet)
>> >> by switching to message based system for all of DMA and IRQs.
>> >>
>> >> Each device would have a message input port and way to output messages.
>> >>
>> >> Examples:
>> >>
>> >> Zero copy memory access from device D1 to D2 to host memory (D3) with
>> >> access broken to page length units and errors occurring on the last
>> >> byte:
>> >> D1 send_msg(ID, MSG_MEM_WRITE, DMA address, length) -> D2
>> >>
>> >>...
>> >>
>> >> IRQ delivery chain D1->D2->D3 with coalescing, messages, delivery
>> >> reporting and EOI:
>> >> D1 send_msg(ID, MSG_IRQ_RAISE, payload) -> D2
>> >
>> > This feels like a terrible idea to me. It introduces an unnecessary RPC
>> > indirection layer without actually solving any of the problems. It just
>> > makes it harder (if not impossible) for the compiler to verify any of
>> > the interfaces between objects.
>>
>> For the memory access case, in practice the interface could be
>> sysbus_memory_rw(DeviceState *parent, target_phys_addr_t addr,
>> target_phys_addr_t size)
>
> Why "parent"?

Parent device or bus host bridge device. Alternatively there could be
a bus handle.

>> in place of send_msg() and
>> sysbus_memory_rw_cb(DeviceState *dev, void *ptr, size_t size, int status)
>> in place of send_replymsg() so we'd have compiler type checks.
>
> I don't see any point point trying to squeeze this through a common message
> passing API. We *could* do that if we really wanted, but It's a lot of hassle.
> If devices are going to end up using wrappers that look a lot like a straight
> API then what's the point?

Without IRQ and other messages, I agree that at this point it would
not make much sense. Do you think this API as straight implementation
would work? Compared to previous attempts for Generic DMA, we'd avoid
any IO vector splitting/reallocations etc.