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

[Anthony Liguori]

Blue Swirl wrote:
> I changed the ESP SCSI and Lance Ethernet on Sparc32 to resolve the IO
> address to physical memory (see patch). ESP works (no zero copy yet),
> Lance doesn't. It looks much better. Because the resolving activity is
> performed in serial steps, unbounded IO vector allocation does not
> happen, but we still could launch as many IO as there are free IO
> vectors.
>   

It is a good cleanup.

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

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

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

Regards,

Anthony Liguori