Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API (v2)
> +/* Return a new IOVector that's a subset of the passed in IOVector. It > should + * be freed with qemu_free when you are done with it. */ > +IOVector *iovector_trim(const IOVector *iov, size_t offset, size_t size); Using qemu_free directly seems a bad idea. I guess we're likely to want to switch to a different memory allocation scheme in the future. The comment is also potentially misleading because iovector_new() doesn't mention anything about having to free the vetor. > +int bdrv_readv(BlockDriverState *bs, int64_t sector_num, >... > +size = iovector_size(iovec); > +buffer = qemu_malloc(size); This concerns me for two reasons: (a) I'm alway suspicious about the performance implications of using malloc on a hot path. (b) The size of the bufer is unbounded. I'd expect multi-megabyte transters to be common, and gigabyte sized operations are plausible. At minimum you need a comment acknowledging that we've considered these issues. > +void *cpu_map_physical_page(target_phys_addr_t addr) > +/* DMA'ing to MMIO, just skip */ > +phys_offset = cpu_get_physical_page_desc(addr); > +if ((phys_offset & ~TARGET_PAGE_MASK) != IO_MEM_RAM) > + return NULL; This is not OK. It's fairly common for smaller devies to use a separate DMA engine that writes to a MMIO region. You also never check the return value of this function, so it will crash qemu. > +void pci_device_dma_unmap(PCIDevice *s, const IOVector *orig, This funcion should not exist. Dirty bits should be set by the memcpy routines. Paul - 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
Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API (v2)
On 07/04/2008, Paul Brook <[EMAIL PROTECTED]> wrote: > > 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). > > Are you sure you aren't confusing the DMA engine itelf (which is just annother > peripheral) with a mechanism for allowing dma engines access to the system. I'm talking about the engine. I want to add a generic one that will detect the no-transformation, no-interrupts case and then possibly use something like IOVector for a whole transfer. - 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
Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API (v2)
> 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). Are you sure you aren't confusing the DMA engine itelf (which is just annother peripheral) with a mechanism for allowing dma engines access to the system. Paul - 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
Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API (v2)
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
Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API (v2)
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). Cheers -- Please do not print this email unless absolutely necessary. Spread environmental awareness. - 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
Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API (v2)
Blue Swirl wrote: > On 4/5/08, Anthony Liguori <[EMAIL PROTECTED]> wrote: > >> This patch introduces a PCI DMA API and some generic code to support other >> DMA >> APIs. It introduces a IOVector type that contains physical address/length >> pairs. These vectors can be translated by the PCI layer and passed either >> to >> generic copying functions or directly to the block or network subsystems. >> > > But cpu_map_physical_page can't be the correct function for > translation for every case. cpu_map_physical_page is the last function you call after you have already translated the IOVector however many times you need to. It's only used within the IO infrastructure (net, block) which are passed fully translated IOVectors. > 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. Regards, Anthony Liguori > - > 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 > - 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
Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API (v2)
On 4/5/08, Anthony Liguori <[EMAIL PROTECTED]> wrote: > This patch introduces a PCI DMA API and some generic code to support other DMA > APIs. It introduces a IOVector type that contains physical address/length > pairs. These vectors can be translated by the PCI layer and passed either to > generic copying functions or directly to the block or network subsystems. But cpu_map_physical_page can't be the correct function for translation for every case. 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. - 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
Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API
Paul Brook wrote: > On Sunday 30 March 2008, Anthony Liguori wrote: > > The entity processing the data shouldn't need to know or care how the > translation is done. PhysIOVector should describe everything it need to know. > Okay, I'll update. >> What could work is if the DMA API functions mapped PhysIOVector => >> PhysIOVector and then the network and block subsystems could operate on >> a PhysIOVector. I have patches that implement vector IO for net and >> block but didn't want to include them in this series to keep things simple. >> > > IMHO this is the only sane way to implement zero-copy. > > This enables zero-copy IO to be preformed without introducing assumptions of phys_ram_base. This API is at the PCI device level to enable support of per-device IOMMU remapping. >>> By my reading it *requires* bridges be zero-copy. For big-endian targets >>> we need to ability to byteswap accesses. >>> >> You mean via ld/st_phys? >> > > By whatever means the bridge deems necessary. The whole point of the DMA API > is that you're transferring a block of data. The API allows intermediate > busses to transform that data (and address) without the block handler needing > to know or care. > > With your current scheme a byteswapping bus has to allocate a single large > buffer for the whole vector, even if the device then ends up copying unto a > local buffer in small chunks. > Oh, I see now. The DMA API should have not just a mechanism to do bulk transfers but also provide an interface to do load/store's that could potentially be byte-swapped. I didn't realize buses did that. Regards, Anthony Liguori > Paul > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API
On Sunday 30 March 2008, Anthony Liguori wrote: > Paul Brook wrote: > > On Saturday 29 March 2008, Anthony Liguori wrote: > >> This patch introduces a PCI DMA API and some generic code to support > >> other DMA APIs. Two types are introduced: PhysIOVector and IOVector. A > >> DMA API maps a PhysIOVector, which is composed of target_phys_addr_t, > >> into an IOVector, which is composed of void *. > > > > Devices should not be using IOVector. They should either use the DMA copy > > routines to copy from a PhysIOVector into a local buffer, or they should > > pass a PhysIOVector to a block/network read/write routine. The DMA API > > should allow devices to be agnostic about how DMA is implemented. They > > should not be trying to manually implement zero copy. > > Someone has to do the translation of PhysIOVector => IOVector. It > doesn't seem logical to me to do it in the IO backend level because the > block subsystem doesn't know how to do that translation. You would have > to pass the PhysIOVector although with a translation function and an > opaque pointer. The entity processing the data shouldn't need to know or care how the translation is done. PhysIOVector should describe everything it need to know. > What could work is if the DMA API functions mapped PhysIOVector => > PhysIOVector and then the network and block subsystems could operate on > a PhysIOVector. I have patches that implement vector IO for net and > block but didn't want to include them in this series to keep things simple. IMHO this is the only sane way to implement zero-copy. > >> This enables zero-copy IO to be preformed without introducing > >> assumptions of phys_ram_base. This API is at the PCI device level to > >> enable support of per-device IOMMU remapping. > > > > By my reading it *requires* bridges be zero-copy. For big-endian targets > > we need to ability to byteswap accesses. > > You mean via ld/st_phys? By whatever means the bridge deems necessary. The whole point of the DMA API is that you're transferring a block of data. The API allows intermediate busses to transform that data (and address) without the block handler needing to know or care. With your current scheme a byteswapping bus has to allocate a single large buffer for the whole vector, even if the device then ends up copying unto a local buffer in small chunks. Paul - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API
Blue Swirl wrote: > On 3/30/08, Anthony Liguori <[EMAIL PROTECTED]> wrote: > >> Blue Swirl wrote: >> > On 3/30/08, Anthony Liguori <[EMAIL PROTECTED]> wrote: >> > >> >> This patch introduces a PCI DMA API and some generic code to support >> other DMA >> >> APIs. Two types are introduced: PhysIOVector and IOVector. A DMA API >> >> maps a PhysIOVector, which is composed of target_phys_addr_t, into an >> IOVector, >> >> which is composed of void *. >> >> >> > >> > This looks like it wouldn't scale to handle the Sparc systems. There >> > we want to make more translation steps from DVMA addresses to physical >> > in DMA controller and IOMMU and only in the final stage to void *. To >> > handle this, probably there should be an opaque parameter and some way >> > to register the translation function. Otherwise the API looks OK. >> > >> >> >> I think having the PCI DMA API translate PhysIOVector => PhysIOVector >> would help. Then it becomes pretty easy to just call the DMA controller >> for additional translation from the IOMMU. >> >> Does that sound right? I don't quite understand what role the opaque >> parameter would serve. >> > > Devices should not need to know about the underlying buses, so they > can be used in different systems. I don't think it will be too hard for a device to support multiple buses if we have the DMA API at the bus level. In the future, the per-bus DMA API may have slight, but important differences. For instance, at some point, PCI devices will be capable of recovering from an IO fault and you'd eventually want the DMA API to reflect this for PCI. Regards, Anthony LIguori > So the translators just call > recursively next ones until we get physical memory. I would use the > opaque parameter as a pointer to each translator's own state > structures. But if you can implement this without the parameter, > great! > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API
On 3/30/08, Anthony Liguori <[EMAIL PROTECTED]> wrote: > Blue Swirl wrote: > > On 3/30/08, Anthony Liguori <[EMAIL PROTECTED]> wrote: > > > >> This patch introduces a PCI DMA API and some generic code to support > other DMA > >> APIs. Two types are introduced: PhysIOVector and IOVector. A DMA API > >> maps a PhysIOVector, which is composed of target_phys_addr_t, into an > IOVector, > >> which is composed of void *. > >> > > > > This looks like it wouldn't scale to handle the Sparc systems. There > > we want to make more translation steps from DVMA addresses to physical > > in DMA controller and IOMMU and only in the final stage to void *. To > > handle this, probably there should be an opaque parameter and some way > > to register the translation function. Otherwise the API looks OK. > > > > > I think having the PCI DMA API translate PhysIOVector => PhysIOVector > would help. Then it becomes pretty easy to just call the DMA controller > for additional translation from the IOMMU. > > Does that sound right? I don't quite understand what role the opaque > parameter would serve. Devices should not need to know about the underlying buses, so they can be used in different systems. So the translators just call recursively next ones until we get physical memory. I would use the opaque parameter as a pointer to each translator's own state structures. But if you can implement this without the parameter, great! - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API
Avi Kivity wrote: > Anthony Liguori wrote: > >>> This looks like it wouldn't scale to handle the Sparc systems. There >>> we want to make more translation steps from DVMA addresses to physical >>> in DMA controller and IOMMU and only in the final stage to void *. To >>> handle this, probably there should be an opaque parameter and some way >>> to register the translation function. Otherwise the API looks OK. >>> >>> >> I think having the PCI DMA API translate PhysIOVector => PhysIOVector >> would help. Then it becomes pretty easy to just call the DMA >> controller for additional translation from the IOMMU. >> >> Does that sound right? I don't quite understand what role the opaque >> parameter would serve. >> >> > > State for the dma controller. > > I think Blue is calling for chaining of dma mappings, no? Something > similar is being proposed for the Linux dma api. > > The way I envision chaining is: virtio-blk calls pci_device_dma_map with a PhysIOVector A pci_device_dma_map calls into PCI IOMMU (if necessary) to translate PhysIOVector A to PhysIOVector B pci_device_dma_map then calls into platform DMA engine to translate PhysIOVector B to PhysIOVector C pci_device_dma_map frees PhysIOVector B and returns PhysIOVector C Regards, Anthony Liguori - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API
Anthony Liguori wrote: >> >> This looks like it wouldn't scale to handle the Sparc systems. There >> we want to make more translation steps from DVMA addresses to physical >> in DMA controller and IOMMU and only in the final stage to void *. To >> handle this, probably there should be an opaque parameter and some way >> to register the translation function. Otherwise the API looks OK. >> > > I think having the PCI DMA API translate PhysIOVector => PhysIOVector > would help. Then it becomes pretty easy to just call the DMA > controller for additional translation from the IOMMU. > > Does that sound right? I don't quite understand what role the opaque > parameter would serve. > State for the dma controller. I think Blue is calling for chaining of dma mappings, no? Something similar is being proposed for the Linux dma api. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API
Blue Swirl wrote: > On 3/30/08, Anthony Liguori <[EMAIL PROTECTED]> wrote: > >> This patch introduces a PCI DMA API and some generic code to support other >> DMA >> APIs. Two types are introduced: PhysIOVector and IOVector. A DMA API >> maps a PhysIOVector, which is composed of target_phys_addr_t, into an >> IOVector, >> which is composed of void *. >> > > This looks like it wouldn't scale to handle the Sparc systems. There > we want to make more translation steps from DVMA addresses to physical > in DMA controller and IOMMU and only in the final stage to void *. To > handle this, probably there should be an opaque parameter and some way > to register the translation function. Otherwise the API looks OK. > I think having the PCI DMA API translate PhysIOVector => PhysIOVector would help. Then it becomes pretty easy to just call the DMA controller for additional translation from the IOMMU. Does that sound right? I don't quite understand what role the opaque parameter would serve. Regards, Anthony Liguori - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API
Paul Brook wrote: > On Saturday 29 March 2008, Anthony Liguori wrote: > >> This patch introduces a PCI DMA API and some generic code to support other >> DMA APIs. Two types are introduced: PhysIOVector and IOVector. A DMA API >> maps a PhysIOVector, which is composed of target_phys_addr_t, into an >> IOVector, which is composed of void *. >> > > Devices should not be using IOVector. They should either use the DMA copy > routines to copy from a PhysIOVector into a local buffer, or they should pass > a PhysIOVector to a block/network read/write routine. The DMA API should > allow devices to be agnostic about how DMA is implemented. They should not be > trying to manually implement zero copy. > Someone has to do the translation of PhysIOVector => IOVector. It doesn't seem logical to me to do it in the IO backend level because the block subsystem doesn't know how to do that translation. You would have to pass the PhysIOVector although with a translation function and an opaque pointer. What could work is if the DMA API functions mapped PhysIOVector => PhysIOVector and then the network and block subsystems could operate on a PhysIOVector. I have patches that implement vector IO for net and block but didn't want to include them in this series to keep things simple. >> This enables zero-copy IO to be preformed without introducing assumptions >> of phys_ram_base. This API is at the PCI device level to enable support of >> per-device IOMMU remapping. >> > > By my reading it *requires* bridges be zero-copy. For big-endian targets we > need to ability to byteswap accesses. > You mean via ld/st_phys? I can add a set of ld/st_vec functions (and even use them in hw/virtio.c). I think operating on a translated vec is the right thing to do as it avoids the translation to be cached. To make ld/st_phys just work, we would have to have some sort of global DMA context. That gets tricky for drivers that use timer callbacks. > Some description (in the form of source comments) of how it's meant to be > used > would also be helpful. > Will do for the next round. Thanks, Anthony Liguori > Paul > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API
On Saturday 29 March 2008, Anthony Liguori wrote: > This patch introduces a PCI DMA API and some generic code to support other > DMA APIs. Two types are introduced: PhysIOVector and IOVector. A DMA API > maps a PhysIOVector, which is composed of target_phys_addr_t, into an > IOVector, which is composed of void *. Devices should not be using IOVector. They should either use the DMA copy routines to copy from a PhysIOVector into a local buffer, or they should pass a PhysIOVector to a block/network read/write routine. The DMA API should allow devices to be agnostic about how DMA is implemented. They should not be trying to manually implement zero copy. > This enables zero-copy IO to be preformed without introducing assumptions > of phys_ram_base. This API is at the PCI device level to enable support of > per-device IOMMU remapping. By my reading it *requires* bridges be zero-copy. For big-endian targets we need to ability to byteswap accesses. Some description (in the form of source comments) of how it's meant to be used would also be helpful. Paul - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API
On 3/30/08, Anthony Liguori <[EMAIL PROTECTED]> wrote: > This patch introduces a PCI DMA API and some generic code to support other DMA > APIs. Two types are introduced: PhysIOVector and IOVector. A DMA API > maps a PhysIOVector, which is composed of target_phys_addr_t, into an > IOVector, > which is composed of void *. This looks like it wouldn't scale to handle the Sparc systems. There we want to make more translation steps from DVMA addresses to physical in DMA controller and IOMMU and only in the final stage to void *. To handle this, probably there should be an opaque parameter and some way to register the translation function. Otherwise the API looks OK. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
