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

[Andrea Arcangeli <aarcange@redhat.com>]

On Fri, Dec 12, 2008 at 01:15:13PM -0600, Anthony Liguori wrote:
> 1) You attempt to map a physical address.  This effectively is a lock or 
> pin operation.

lock or pin for what? There's nothing to pin or lock here. Perhaps one
day we'll have to lock or pin against something, dunno, then we'll add
whatever pin or lock, otherwise why don't we also thread qcow2 while
we're at it, sounds more worth it than adding a lock or pin that isn't
actually needed.

>  a) In the process of this, you get a virtual address that you can 
> manipulate.

That's what can_dma does. If it can, it generates a dma address backed
by ram it does. But if it can't, it won't. This only works for direct I/O.

> 2) You do your IO to the virtual address

This is done by dma.c.

> 3) You indicate how much of the memory you have dirtied

That is done by the post_dma handler called by dma.c.

> 4) You unmap or unlock that memory region.  The virtual address is now no 
> longer valid.

Again not needed.

> This could correspond to a:
>
> void *cpu_physical_memory_map(target_phys_addr_t addr, ram_addr_t size, int 
> is_write);
>
> void cpu_physical_memory_unmap(target_physical_addr_t addr, ram_addr_t 
> size, void *mapping, int is_dirty);

So you mean renaming can_dma to map and post_dma to unmap and not
adding any lock/pin at all that would otherwise gratuitously slow it
down?

I've no idea why you should ever want to call any unmap for reads
though... and calling it with your naming conventions, and not
invoking it for reads (there's absolutely no good reason to invoke any
unmap methods for reads, and it can only hurt at runtime) would be
weird in my view.