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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
