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

[Blue Swirl]

On 12/16/08, Avi Kivity <address@hidden> wrote:
> 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.

Should the bouncing be something more much complex, for example
negotiated between the devices? Or maybe the devices set up a
transforming and non-transforming channel (which the other end should
be able to transform some more) and use them as needed?

In the Lance case, some of the DMA is byte swapped and some not,
depending on the memory region used, some is swapped because of a
global bit in a register and finally the Sparc32 DMA controller
reverses the swapping.