|Subject:||Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO|
|Date:||Sun, 14 Dec 2008 20:09:39 -0600|
|User-agent:||Thunderbird 22.214.171.124 (X11/20080925)|
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
|[Prev in Thread]||Current Thread||[Next in Thread]|