qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Brook
Subject: Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs
Date: Sun, 13 Jun 2010 20:38:35 +0100
User-agent: KMail/1.13.3 (Linux/2.6.33-2-amd64; KDE/4.4.4; x86_64; ; )

> >> 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.

A device has no way of knowing where that bust host bridge is, and this may be 
the wrong device anyway. The access may be directed at another device on the 
same bus.  A bus handle is trivial to derive this from the device itself.

> > 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.

We have already merged a "generic DMA" infrastructure 
(cpu_physical_memory_map). See also dma-helpers.c for code that uses this to 
implement zero-copy transfers to/from block devices.

This is missing code to allow manipulation by intermediate bus/bridges, but I 
believe the basic API is fairly sound. Addition of a device handle or error 
reporting should be possible without requiring major changes to the device 
code.

Paul



reply via email to

[Prev in Thread] Current Thread [Next in Thread]