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
