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

[Anthony Liguori <anthony@codemonkey.ws>]

Paul Brook wrote:
>>> That's pointless; cirrus for example has 8MB of mmio while a
>>> cpu-to-vram blit is in progress, and some random device we'll add
>>> tomorrow could easily introduce more.  Our APIs shouldn't depend on
>>> properties of emulated hardware, at least as much as possible.
>>>       
>> One way to think of what I'm suggesting, is that if for every
>> cpu_register_physical_memory call for MMIO, we allocated a buffer, then
>> whenever map() was called on MMIO, we would return that already
>> allocated buffer.  The overhead is fixed and honestly relatively small.
>> Much smaller than dma.c proposes.
>>     
>
> I Wouldn't be surprised if some machines had a large memory mapped IO space.  
> Most of it might not be actively used, but once you start considering 64-bit 
> machines on 32-bit hosts these allocations would become problematic.
>   

At some level, any DMA API would fall apart here.  Certain IO operations 
simply cannot be split (such as network send).  If you pass don't pass a 
flag to the map function that says you can handle partial results, you 
must cope with map() returning NULL (by dropping the packet).

Since MMIO space is something we control as we implement device 
emulation, we can assert that this isn't a problem today, and then deal 
with that particular special case when we come to it.

Regards,

Anthony Liguori