search for: dma_api

...e 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 p...

...e 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 p...

...affected too. > We don't want that. > > So let's find a way to make sure it's just power secure guest for now > pls. Yes, my understanding is that they turn ACCESS_PLATFORM on. And because of that, IIUC this patch wouldn't affect them because in their platform vring_use_dma_api() returns true earlier in the "if !virtio_has_iommu_quirk(vdev)" condition. > I also think we should add a dma_api near features under virtio_device > such that these hacks can move off data path. Sorry, I don't understand this. > By the way could you please respond about...

...affected too. > We don't want that. > > So let's find a way to make sure it's just power secure guest for now > pls. Yes, my understanding is that they turn ACCESS_PLATFORM on. And because of that, IIUC this patch wouldn't affect them because in their platform vring_use_dma_api() returns true earlier in the "if !virtio_has_iommu_quirk(vdev)" condition. > I also think we should add a dma_api near features under virtio_device > such that these hacks can move off data path. Sorry, I don't understand this. > By the way could you please respond about...

...t that. > > > > So let's find a way to make sure it's just power secure guest for now > > pls. > > Yes, my understanding is that they turn ACCESS_PLATFORM on. And because > of that, IIUC this patch wouldn't affect them because in their platform > vring_use_dma_api() returns true earlier in the > "if !virtio_has_iommu_quirk(vdev)" condition. Let's just say I don't think we should assume how the specific hypervisor behaves. It seems to follow the spec and so should Linux. > > I also think we should add a dma_api near features under...

...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 suppo...

...d to get DMA API implementation in with a conservative policy like this rather than waiting until we achieve perfection. I'm tired of carrying these patches around. I changed queue allocation around a bit in this version. Per Michael's request, we no longer use dma_zalloc_coherent in the !dma_api case. Instead we use alloc_pages_exact, just like the current code does. This simplifies the ring address accessors, because they can always load from the dma addr rather than depending on vring_use_dma_api themselves. There's an odd warning in here if the ring's physical address doesn'...

...d to get DMA API implementation in with a conservative policy like this rather than waiting until we achieve perfection. I'm tired of carrying these patches around. I changed queue allocation around a bit in this version. Per Michael's request, we no longer use dma_zalloc_coherent in the !dma_api case. Instead we use alloc_pages_exact, just like the current code does. This simplifies the ring address accessors, because they can always load from the dma addr rather than depending on vring_use_dma_api themselves. There's an odd warning in here if the ring's physical address doesn'...

...l platforms that I'm aware of. That doesn't mean that there isn't anything that I missed. Thanks to everyone for putting up with the development of this series. Hopefully it'll be the end of DMA issues in virtio. :) Changes from v3: - virtio_pci only asks virtio_ring to use the DMA_API if !PCI_DMA_BUS_IS_PHYS. - Reduce tools/virtio breakage. It's now merely as broken as before instead of being even more broken. - Drop the sg_next changes -- Rusty's version is better. Changes from v2: - Reordered patches. - Fixed a virtio_net OOPS. Changes from v1: - Using th...

...l platforms that I'm aware of. That doesn't mean that there isn't anything that I missed. Thanks to everyone for putting up with the development of this series. Hopefully it'll be the end of DMA issues in virtio. :) Changes from v3: - virtio_pci only asks virtio_ring to use the DMA_API if !PCI_DMA_BUS_IS_PHYS. - Reduce tools/virtio breakage. It's now merely as broken as before instead of being even more broken. - Drop the sg_next changes -- Rusty's version is better. Changes from v2: - Reordered patches. - Fixed a virtio_net OOPS. Changes from v1: - Using th...

Hi all, Here''s a work in progress series whcih does a partial revert of the previous swiotlb changes, and does a partial replacement with Becky Bruce''s series. The most important difference is Becky''s use of phys_addr_t rather than page+offset to represent arbitrary pages. This turns out to be simpler. I didn''t replicate the map_single_page changes, since