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

[Avi Kivity]

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