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

Avi Kivity
2008-12-14T17:01:45Z

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