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

[Anthony Liguori <anthony@codemonkey.ws>]

Andrea Arcangeli wrote:
> 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.
>   

Please try to understand what people are suggesting to you.  I have no 
idea why you bring up threading qcow2.  This is not a topic that hasn't 
been discussed at great length before.  You didn't even fix any of the 
comments people made against the series since the last time you posted it.

>>  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.
>   

No, can_dma does two things in one.  It checks to see if there physical 
region is MMIO, and it returns phys_ram_base + PA otherwise.

This is not helpful though in the general case.  It's not an API that 
extends well for things like memory hotplug, etc.

If we're not building APIs for the future, what's the point of this 
exercise in the first place?  virtio already has the bits to do 
zero-copy memory transfers.

Regards,

Anthony Liguori