Re: [Qemu-devel] [PATCH 1/9] dma-helpers: Expose the sg mapping logic

[Paolo Bonzini]

On 25/02/2016 12:19, Alex Pyrgiotis wrote:
>> The patch could first introduce address_space_map_direct that never uses
>> the bounce buffer.  dma-helpers.c can call address_space_map_direct and,
>> if it fails, proceed to allocate (and fill if writing to the device) a
>> bounce buffer.
> 
> You mean that address_space_map_direct() is a copy of the
> address_space_map() code, minus the bounce buffer part which will be
> handled in dma-helpers.c? If so, I agree.

Yes.  In particular minus the:

    if (!memory_access_is_direct(mr, is_write))

part, hence the name. :)  If direct access isn't possible,
address_space_map_direct would always return NULL, like
address_space_map does when bounce.in_use is already true.

> Also, the buffer should be removed from address_space_unmap.

Right, though only after address_space_map_direct is renamed to
address_space_map.  That's also the point where cpu_register_map_client
disappears, and other parts of dma-helpers.c too such as the bottom half.

>> Since the QEMUSGList is mapped and unmapped
>> beginning-to-end, you can just use a FIFO queue.  The FIFO queue stores
>> a (QEMUSGList, buffer) tuple.
> 
> I suppose that this queue is stored in the dbs structure of dma-helpers?
> If so, I agree.

Yes.

>> Then, once the bounce buffer is implemented within dma-helpers.c, you
>> remove address_space_map and rename address_space_map_direct to
>> address_space_map.  cpu_register_map_client goes away.
> 
> What about the other users of address_space_map()? Is the bounce buffer
> used only for DMA operations? If so, I agree. Else, we need a fallback.

Other users usually fail if address_space_map cannot return a mapping as
big as requested.  They also do not use cpu_register_map_client.  Both
shortcomings mean that in practice they do not support the bounce buffer.

Paolo