andrzej zaborowski wrote: > On 06/04/2008, Anthony Liguori <[EMAIL PROTECTED]> 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 > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
