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

[Avi Kivity <avi@redhat.com>]

Anthony Liguori wrote:
>> There are still some issues I'm not happy yet:
>> - handling of access violations: resolving should stop before the bad
>> page, the transfers should be done until that and then post error.
>> - bounce buffers needed for Lance byte swapping are not well designed 
>> (stack)
>>   
>
> I think you could approach the bouncing via a map/unmap API but I'm 
> not sure.  You would need a map() function to take a virtual address 
> which is sort of weird.  That would allow you to stack them in an 
> arbitrary fashion though.
>

I think that's broken.  iommus converts physical addresses to physical 
addresses (or bus addresses), possibly generating faults along the way, 
and depending on the iommu context.  map()/unmap() converts physical/bus 
addresses to virtual addresses, possibly bouncing.  Except for both 
doing conversions, they're very different.

>> This lead me to the thought that maybe we should not hide the bounce
>> buffer activity, but instead make it more explicit for the device that
>> needs bouncing. For the other device, the buffering or lack of it
>> should be opaque.
>>   
>
> I think that's reasonable.

I don't understand.  It's not a device that needs bouncing, it's a 
particular transfer.  This could be either due to the transfer targeting 
mmio, or due to the transfer requiring a transformation.

>
>> Also the virtual-to-physical address resolution API could be generic,
>> ie all resolver functions should take same parameters so that the
>> devices would not need to know the next higher level device.
>>   
>
> Yes.  I think this is key.  The only observation I would make is that 
> the resolution API should have some sort of release function (so 
> map/unmap, lock/unlock, whatever).

Also, in order to support chaining, the input and output parameters need 
to be the same (both sglists).

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