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

Avi Kivity
2008-12-16T09:42:10Z

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