search for: dma_map_single

It seems the problems running mthca in a Xen domU have uncovered a bug in mthca: mthca uses dma_sync_single in mthca_arbel_write_mtt_seg() and mthca_arbel_map_phys_fmr() to sync the MTTs that get written. However, Documentation/DMA-API.txt says: void dma_sync_single(struct device *dev, dma_addr_t dma_handle, size_t size, enum dma_data_direction direction) synchronise a single

While writing a driver for a device doing lots of DMA I''ve hit an "swiotlb_full()" problem. This surprised me somewhat as I wouldn''t have expected to need the use of the software TLB - it''s a 64 bit capable device on a server with only 2 GB of RAM, and so I''d have expected to be using a hardware TLB. Is this a peculiarity of Xen, or should I be right

I am rewriting the TX path in the GPLPV drivers and in its current form I am readily able to crash the system (eg Dom0 and everything else running) from DomU. xen is 3.3.1, linux is at most a week behind the 3.3.1 release date. My Windows DomU boots up, fails to get an IP address (yes, the TX path is broken), and then a short time later the system has rebooted. I don''t know exactly

...r->pdev->dev, sz, + &tq->buf_info_pa, GFP_KERNEL); if (!tq->buf_info) goto err; @@ -578,7 +583,8 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32 ring_idx, break; } - rbi->dma_addr = pci_map_single(adapter->pdev, + rbi->dma_addr = dma_map_single( + &adapter->pdev->dev, rbi->skb->data, rbi->len, PCI_DMA_FROMDEVICE); } else { @@ -595,7 +601,8 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32 ring_idx, rq->stats.rx_buf_alloc_failure++; break; } - rbi->dma_addr = pci...

...r->pdev->dev, sz, + &tq->buf_info_pa, GFP_KERNEL); if (!tq->buf_info) goto err; @@ -578,7 +583,8 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32 ring_idx, break; } - rbi->dma_addr = pci_map_single(adapter->pdev, + rbi->dma_addr = dma_map_single( + &adapter->pdev->dev, rbi->skb->data, rbi->len, PCI_DMA_FROMDEVICE); } else { @@ -595,7 +601,8 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32 ring_idx, rq->stats.rx_buf_alloc_failure++; break; } - rbi->dma_addr = pci...

...CT xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 xfrm_nalgo crypto_api dm_mirror dm_multipath dm_mod parport_pc lp parport 3c59x pcspkr mii xenblk ext3 jbd uhci_hcd ohci_hcd ehci_hcd CPU: 0 EIP: 0061:[<c040a39c>] Not tainted VLI EFLAGS: 00010292 (2.6.18-92.el5xen #1) EIP is at dma_map_single+0x12d/0x147 eax: 0000002f ebx: 00000000 ecx: 00000001 edx: f5416000 esi: 38f59e02 edi: 00000001 ebp: 0000004e esp: c071bdbc ds: 007b es: 007b ss: 0069 Process swapper (pid: 0, ti=c071b000 task=c066e2c0 task.ti=c06e6000) Stack: c0621abd c07fc448 008a8e02 00000000 cf914400 cf5db200 c0...

...es plus > an ifdef powerpc will be functionally equivalent, just uglier. So for powerpc, it's a 2 liner inside virtio-pci, but yes, it might be more of a problem for s390, I'm not too sure what they do in that area. > Bigger quirk: on a standard s390 virtio guest configuration, > dma_map_single etc will fail to link. Yuck > I tried this in v1 of these > patches. So we can poke at the archdata all day, but we can't build a > kernel like that :( I would like the s390 people to chime in here, it still looks like the best way to go if they can fix things on their side :-)...

...es plus > an ifdef powerpc will be functionally equivalent, just uglier. So for powerpc, it's a 2 liner inside virtio-pci, but yes, it might be more of a problem for s390, I'm not too sure what they do in that area. > Bigger quirk: on a standard s390 virtio guest configuration, > dma_map_single etc will fail to link. Yuck > I tried this in v1 of these > patches. So we can poke at the archdata all day, but we can't build a > kernel like that :( I would like the s390 people to chime in here, it still looks like the best way to go if they can fix things on their side :-)...

...files changed, 83 insertions(+), 136 deletions(-) delete mode 100644 include/linux/dma-attrs.h diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 45ef3f279c3b..24f9688bb98a 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -369,35 +369,32 @@ See also dma_map_single(). dma_addr_t dma_map_single_attrs(struct device *dev, void *cpu_addr, size_t size, enum dma_data_direction dir, - struct dma_attrs *attrs) + unsigned long attrs) void dma_unmap_single_attrs(struct device *dev, dma_addr_t dma_addr, size_t size, enum dma_data_dire...

...nmapped, or only when the buffer is actually freed to cache IOMMU mappings. > > Doing IOMMU mapping for the whole buffer with dma_map_sg is also faster than > mapping page by page, because you can do only one TLB invalidate in the end > of the loop instead of after every page if you use dma_map_single. > > All of these would talk for having IOMMU and GMMU mapping loops separate. > This patch set does not implement both the advantages above, but your > suggestion would take us further away from that than Vince's version. Aha, looks like both Vince and I overlooked this point. So...

Hi Linus, My for-linus branch has a one line fix: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus Sage hit a deadlock with ceph on btrfs, and Josef tracked it down to a regression in our initial rc1 pull. When doing nocow writes we were sometimes starting a transaction with locks held. Josef Bacik (1) commits (+1/-0): Btrfs: release path before starting

On Thu, Apr 16, 2015 at 8:06 PM, Vince Hsu <vinceh at nvidia.com> wrote: > This patch implements a way to aggregate the small pages and make them be > mapped as big page(s) by utilizing the platform IOMMU if supported. And then > we can enable compression support for these big pages later. > > Signed-off-by: Vince Hsu <vinceh at nvidia.com> > --- >

We can't just do virt_to_phys() on memory that we pass to the device and expect it to work in presence of a virtual IOMMU. We need to add IOMMU mappings for such DMAs to work correctly. Fix that with pci_alloc_consistent() where possible, or pci_map_single() where the mapping is short-lived or we don't control the allocation (netdev). Also fix two small bugs: 1) use after free of

We can't just do virt_to_phys() on memory that we pass to the device and expect it to work in presence of a virtual IOMMU. We need to add IOMMU mappings for such DMAs to work correctly. Fix that with pci_alloc_consistent() where possible, or pci_map_single() where the mapping is short-lived or we don't control the allocation (netdev). Also fix two small bugs: 1) use after free of

On Tue, 2014-09-02 at 16:42 -0700, Andy Lutomirski wrote: > But there aren't any ACPI systems with both virtio-pci and IOMMUs, > right? So we could say that, henceforth, ACPI systems must declare > whether virtio-pci devices live behind IOMMUs without breaking > backward compatibility. I don't know for sure whether that's the case and whether we can rely on that not

On Tue, 2014-09-02 at 16:42 -0700, Andy Lutomirski wrote: > But there aren't any ACPI systems with both virtio-pci and IOMMUs, > right? So we could say that, henceforth, ACPI systems must declare > whether virtio-pci devices live behind IOMMUs without breaking > backward compatibility. I don't know for sure whether that's the case and whether we can rely on that not

...__init spiderpci_pci_setup_chip(struct pci_controller *phb, > dummy_page_va = kmalloc(PAGE_SIZE, GFP_KERNEL); > if (!dummy_page_va) { > pr_err("SPIDERPCI-IOWA:Alloc dummy_page_va failed.\n"); > - return -1; > + return -ENOMEM; > } > > dummy_page_da = dma_map_single(phb->parent, dummy_page_va, > @@ -137,7 +137,7 @@ int __init spiderpci_iowa_init(struct iowa_bus *bus, void *data) > if (!priv) { > pr_err("SPIDERPCI-IOWA:" > "Can't allocate struct spiderpci_iowa_private"); > - return -1; > + return -EN...

...32() that should have been a cpu_to_le64() > > Acked-by: George Zhang <georgezhang at vmware.com> > Acked-by: Aditya Sarwade <asarwade at vmware.com> > Signed-off-by: Andy King <acking at vmware.com> Please use dma_alloc_coherent() (or in fact dma_zalloc_coherent()), dma_map_single() et al., because they are preferred and in particular allow specification of GFP_* flags.

This version addresses Sergei's comments. o Fixed description and added Reported-by o Removed NULL check for kfree()

...with some NULL ops on platforms that need it. > > The only issue with that is the location of the dma ops is arch > specific, so that one function will contain some ifdefs, but the rest of > the code can just use the DMA API. Bigger quirk: on a standard s390 virtio guest configuration, dma_map_single etc will fail to link. I tried this in v1 of these patches. So we can poke at the archdata all day, but we can't build a kernel like that :( So until the dma_ops pointer move into struct device and CONFIG_HAS_DMA becomes mandatory (or mandatory enough that virtio can depend on it), I don'...