Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO

[Avi Kivity]

Anthony Liguori wrote:
>>
>> - DMA into mmio regions; this requires bouncing
>
> The map() API I proposed above should do bouncing to MMIO regions.  To
> deal with unbounded allocation, you can simply fail when the mapping
> allocation has reached some high limit.  Calling code needs to cope
> with the fact that map'ing may succeed or fail.

There are N users of this code, all of which would need to cope with the
failure.  Or there could be one user (dma.c) which handles the failure
and the bouncing.

dma.c _is_ a map/unmap api, except it doesn't expose the mapped data,
which allows it to control scheduling as well as be easier to use.

>
>> - DMA with an associated transform (xor, byteswap); also requires
>> bouncing
>
> At this layer of the API, this is unnecessary.  At the PCI layer, you
> would need to handle this and I'd suggest taking the same approach as
> above.

I agree to _map()/_unmap(), but it's not a solution by itself.

>
>> In turn, bouncing requires splitting large requests to avoid
>> unbounded memory allocation.
>>
>> While I think _map/_unmap is an improvement over can_dma(), this API
>> can't handle bounded bouncing, and so a separate layer (dma.c) is
>> still necessary.
>
> I think it can handled bounded bouncing fine.  It's a matter of
> ensuring the bounce buffer max is sufficiently large and ensuring that
> any client code can cope with map failures.  In fact, there probably
> needs to be a notifiers API that is invoked whenever an unmap()
> happens so that if an asynchronous request is waiting because of a map
> failure, it can be notified as to when it should try again.

Right, but who would it notify?

We need some place that can deal with this, and it isn't
_map()/_unmap(), and it isn't ide.c or scsi.c.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.