Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API (v2)

[Anthony Liguori <anthony@codemonkey.ws>]

andrzej zaborowski wrote:
> On 06/04/2008, Anthony Liguori <anthony@codemonkey.ws> wrote:
>   
>> Blue Swirl wrote:
>>     
>>>  To support Sparc IOMMU and DMA controller
>>> I need a way to call a series of different translation functions
>>> depending on the bus where we are. For the byte swapping case the
>>> memcpy functions must be dynamic as well.
>>>       
>>  Does DMA really byte-swap?  I know PCI controllers byte swap within the
>> configuration space but I didn't think they byte-swapped DMA transfers.  I'm
>> not even sure how that would work.
>>     
>
> As a note, the DMA controllers in the ARM system-on-chip's can
> byte-swap, do 90deg rotation of 2D arrays, transparency (probably
> intened for image blitting, but still available on any kind of
> transfers), etc., and most importantly issue interrupts on reaching
> different points of a transfer.  It is not worth worrying about them
> in this API.  I have been for some time wanting to make a separate api
> called soc_dma whose task would be using simply memcpy (or zero-copy)
> in the most basic case (interrupts off, no transparency,
> same-endianness endpoints), as these properties are common for DMA on
> the TI OMAPs, the Intel PXAs and the Samsung S3Cs (which otherwise
> have little in common).
>   

Wow.  So this attempt clearly doesn't encompass all of these features, 
but I don't think anything about it makes it more difficult to implement 
an API capable of doing these things.  It introduces an IOVector which 
is an abstraction of a DMA request, and the devices for the most part 
access the vector with copying functions.  We'll have to have a dual mode.

This is why I had a PhysIOVector and IOVector in my original patch.  
Passing physical addresses to the block/net backends insist on a dual 
mode.  One where it can map those addresses directly and another where 
it perform IO to a temporary location and then calls to some other code 
to copy the data.

When you have the PCI device generate an IOVector containing virtual 
addresses, the PCI device itself can decide whether to pass through 
direct mappings of the guests memory or a temporary buffer.  It can then 
perform whatever transformations it needs on unmapping.

So I think we can either ignore these transformations for now and go 
with the current API or go back to the former API which would allow 
transformations but that Paul wasn't a big fan of.

Regards,

Anthony Liguori

> Cheers
>