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

[Avi Kivity]

Andrea Arcangeli wrote:
> To me map/unmap looks backwards. There's absolutely no point at all to
> pretend that RAM isn't always mapped.

Actually, with Xen, RAM may be unmapped due do Xen limitations when qemu 
runs on dom0 mode.  But I think map/unmap makes sense even disregarding 
Xen:  if we add memory hotunplug, we need to make sure we don't unplug 
memory that has pending dma operations on it.  map/unmap gives us the 
opportunity to refcount memory slots.

> The whole concept of having to map something is flawed, there's
> nothing to map. At most you've to take a read lock to prevent future
> memory hotplug to change the memory layout from under you, but the
> concept of mapping has nothing to do with that. RAM is always mapped,
> and mmio has to be emulated anyway so it's worthless to map it.
>   

We can't get all dma to stop during hotunplug, since net rx operations 
are long-running (infinite if there is no activity on the link).

IMO, we do want map/unmap, but this would be just a rename of can_dma 
and friends, and wouldn't have at this time any additional 
functionality.  Bouncing has to happen where we have the ability to 
schedule the actual operation, and that's clearly not map/unmap.

--
error compiling committee.c: too many arguments to function