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

["Blue Swirl" <blauwirbel@gmail.com>]

On 12/16/08, Anthony Liguori <anthony@codemonkey.ws> wrote:
> 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.

I'd still like to keep resolving virtual addresses to physical
addresses separate from physical address to host pointer mapping. I
think this was the enlightening discovery we made earlier.

The generic resolving API should look something like

int (*resolve)(target_phys_addr_t address_in, target_phys_addr_t
length_in, target_phys_addr_t &address_out, target_phys_addr_t
&length_out)

whereas the map/unmap API would be as you specified earlier.

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

I'm not so sure resolving works the same symmetric way, because the
virtual to physical mapping will change over time because of guest
activity. We could cache the resolved translations, but then there
should be a way to invalidate the cache entries throughout the device
chain with callbacks etc.