search for: config_dma_api_debug

...use case for me is to enable virtio on Xen guests. >> For that to work, we need vring to support DMA address translation >> as well as a corresponding change to virtio_pci or to another >> driver. >> >> With this patch, if enabled, virtfs survives kmemleak and >> CONFIG_DMA_API_DEBUG. >> >> Signed-off-by: Andy Lutomirski <luto at kernel.org> >> --- >> drivers/virtio/Kconfig | 2 +- >> drivers/virtio/virtio_ring.c | 190 +++++++++++++++++++++++++++++++-------- >> tools/virtio/linux/dma-mapping.h | 17 ++++ >> 3 fi...

...use case for me is to enable virtio on Xen guests. >> For that to work, we need vring to support DMA address translation >> as well as a corresponding change to virtio_pci or to another >> driver. >> >> With this patch, if enabled, virtfs survives kmemleak and >> CONFIG_DMA_API_DEBUG. >> >> Signed-off-by: Andy Lutomirski <luto at kernel.org> >> --- >> drivers/virtio/Kconfig | 2 +- >> drivers/virtio/virtio_ring.c | 190 +++++++++++++++++++++++++++++++-------- >> tools/virtio/linux/dma-mapping.h | 17 ++++ >> 3 fi...

...ULE_FORCE_UNLOAD=y/' config-nodebug @perl -pi -e 's/# CONFIG_SYSCTL_SYSCALL_CHECK is not set/CONFIG_SYSCTL_SYSCALL_CHECK=y/' config-nodebug @perl -pi -e 's/# CONFIG_DEBUG_NOTIFIERS is not set/CONFIG_DEBUG_NOTIFIERS=y/' config-nodebug @perl -pi -e 's/# CONFIG_DMA_API_DEBUG is not set/CONFIG_DMA_API_DEBUG=y/' config-nodebug @perl -pi -e 's/# CONFIG_PM_TEST_SUSPEND is not set/CONFIG_PM_TEST_SUSPEND=y/' config-generic @perl -pi -e 's/# CONFIG_PM_ADVANCED_DEBUG is not set/CONFIG_PM_ADVANCED_DEBUG=y/' config-generic @perl -pi -e...

...6% > of a PAGE_SIZE. Yes, we basically waste the whole page. I'm ok with that if the benefit is to play nice with the kernel APIs. > > For practical > > matters: DMA debugging will complain about misuse of a specific device or > > driver. > > > > Do you mean CONFIG_DMA_API_DEBUG and CONFIG_DMA_API_DEBUG_SG? I've been > running with those and did not see any complaints. Maybe we should > clarify this one offline... I didn't mean to imply that there are bugs already - just that when used as intended the DMA_DEBUG_API can complain about stuff like "your de...

...t; > The immediate use case for me is to enable virtio on Xen guests. > For that to work, we need vring to support DMA address translation > as well as a corresponding change to virtio_pci or to another > driver. > > With this patch, if enabled, virtfs survives kmemleak and > CONFIG_DMA_API_DEBUG. > > Signed-off-by: Andy Lutomirski <luto at kernel.org> > --- > drivers/virtio/Kconfig | 2 +- > drivers/virtio/virtio_ring.c | 190 +++++++++++++++++++++++++++++++-------- > tools/virtio/linux/dma-mapping.h | 17 ++++ > 3 files changed, 172 insertions...

...; device ever ends up > behind an IOMMU or swiotlb. > > The immediate use case for me is to enable virtio on Xen guests. > For that to work, we need this fix as well as a corresponding > fix to virtio_pci or to another driver. > > With this patch, virtfs survives kmemleak and CONFIG_DMA_API_DEBUG. > virtio-net warns (correctly) about DMA from the stack in > virtnet_set_rx_mode. > > This breaks s390's defconfig. The default configuration for s390 > does virtio through a KVM-specific interface, but that configuration > does not support DMA. I could modify this patch t...

...; device ever ends up > behind an IOMMU or swiotlb. > > The immediate use case for me is to enable virtio on Xen guests. > For that to work, we need this fix as well as a corresponding > fix to virtio_pci or to another driver. > > With this patch, virtfs survives kmemleak and CONFIG_DMA_API_DEBUG. > virtio-net warns (correctly) about DMA from the stack in > virtnet_set_rx_mode. > > This breaks s390's defconfig. The default configuration for s390 > does virtio through a KVM-specific interface, but that configuration > does not support DMA. I could modify this patch t...

...r ends up behind an IOMMU or swiotlb. The immediate use case for me is to enable virtio on Xen guests. For that to work, we need vring to support DMA address translation as well as a corresponding change to virtio_pci or to another driver. With this patch, if enabled, virtfs survives kmemleak and CONFIG_DMA_API_DEBUG. Signed-off-by: Andy Lutomirski <luto at kernel.org> --- drivers/virtio/Kconfig | 2 +- drivers/virtio/virtio_ring.c | 190 +++++++++++++++++++++++++++++++-------- tools/virtio/linux/dma-mapping.h | 17 ++++ 3 files changed, 172 insertions(+), 37 deletions(-) create mode 1...

...ail if a physical "virtio" device ever ends up behind an IOMMU or swiotlb. The immediate use case for me is to enable virtio on Xen guests. For that to work, we need this fix as well as a corresponding fix to virtio_pci or to another driver. With this patch, virtfs survives kmemleak and CONFIG_DMA_API_DEBUG. virtio-net warns (correctly) about DMA from the stack in virtnet_set_rx_mode. This breaks s390's defconfig. The default configuration for s390 does virtio through a KVM-specific interface, but that configuration does not support DMA. I could modify this patch to stub out the DMA API calls i...

...ind an IOMMU or swiotlb. > > > > The immediate use case for me is to enable virtio on Xen guests. > > For that to work, we need this fix as well as a corresponding > > fix to virtio_pci or to another driver. > > > > With this patch, virtfs survives kmemleak and CONFIG_DMA_API_DEBUG. > > virtio-net warns (correctly) about DMA from the stack in > > virtnet_set_rx_mode. > > > > This breaks s390's defconfig. The default configuration for s390 > > does virtio through a KVM-specific interface, but that configuration > > does not support DMA...

...@@ -744,7 +744,7 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle, .gfp = gfp, .prot = prot, .caller = caller, - .want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs), + .want_vaddr = ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) == 0), }; #ifdef CONFIG_DMA_API_DEBUG @@ -887,7 +887,7 @@ static void __arm_dma_free(struct device *dev, size_t size, void *cpu_addr, .size = PAGE_ALIGN(size), .cpu_addr = cpu_addr, .page = page, - .want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs), + .want_vaddr = ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) == 0),...

This fixes virtio on Xen guests as well as on any other platform on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches, everything works. There

This fixes virtio on Xen guests as well as on any other platform on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches, everything works. There

Hello, I''m facing a strange issue with network card PCI passthrough on my openwrt test domU. - With network PCI passthrough, DNS lookup failed for some domains (exemple, google.com) but not for other (free.fr my ISP, or my domain jbfavre.org). I can ping an IP address without any problem. - Starting domU as a "normal" (ie without PCI passthrough), no problem. As far as I can

...g a new one (patch 5). - Finally, buffers that are used by the kernel should be requested to be coherent (page 6). Changes since v3: - Only use the DMA allocator for BOs that strictly require to be coherent - Fixed the way pages are mapped to the GPU on platform devices - Thoroughly checked with CONFIG_DMA_API_DEBUG that there were no API violations Alexandre Courbot (6): drm/ttm: expose CPU address of DMA-allocated pages drm/nouveau: map pages using DMA API on platform devices drm/nouveau: introduce nv_device_is_cpu_coherent() drm/nouveau: synchronize BOs when required drm/nouveau: implement explic...

This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. This appears to work on native and Xen x86_64 using both modern and legacy virtio-pci. It also appears to work on arm and arm64. It definitely won't work as-is on s390x, and

This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. This appears to work on native and Xen x86_64 using both modern and legacy virtio-pci. It also appears to work on arm and arm64. It definitely won't work as-is on s390x, and

This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. Changes from v2: - Fix really embarrassing bug. This version actually works. Changes from v1: - Fix an endian conversion error causing a BUG to hit. - Fix a DMA ordering issue

This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. Changes from v2: - Fix really embarrassing bug. This version actually works. Changes from v1: - Fix an endian conversion error causing a BUG to hit. - Fix a DMA ordering issue

This fixes virtio on Xen guests as well as on any other platform that uses virtio_pci on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches,