[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Avi Kivity
Subject: Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO
Date: Tue, 16 Dec 2008 11:41:59 +0200
User-agent: Thunderbird (X11/20081119)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]