similar to: [PATCH] xen/arm64: do not call the swiotlb functions twice

Hi all, this patch series enables xen-swiotlb on arm and arm64. It has been heavily reworked compared to the previous versions in order to achieve better performances and to address review comments. We are not using dma_mark_clean to ensure coherency anymore. We call the platform implementation of map_page and unmap_page. We assume that dom0 has been mapped 1:1 (physical address == machine

Normal boot path on system with iommu support: swiotlb buffer will be allocated early at first and then try to initialize iommu, if iommu for intel or AMD could setup properly, swiotlb buffer will be freed. The early allocating is with bootmem, and could panic when we try to use kdump with buffer above 4G only, or with memmap to limit mem under 4G. for example: memmap=4095M$1M to remove memory

Normal boot path on system with iommu support: swiotlb buffer will be allocated early at first and then try to initialize iommu, if iommu for intel or AMD could setup properly, swiotlb buffer will be freed. The early allocating is with bootmem, and could panic when we try to use kdump with buffer above 4G only, or with memmap to limit mem under 4G. for example: memmap=4095M$1M to remove memory

On Thu, 2018-05-10 at 12:28 +0200, Mike Galbraith wrote: > On Thu, 2018-05-10 at 11:10 +0200, Mike Galbraith wrote: > > Greetings, > > > > When box is earning its keep, nouveau/swiotlb grumble.. a LOT. The > > below is from master.today. > > > > [12594.640959] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) > > [12594.693000] nouveau

Greetings, When box is earning its keep, nouveau/swiotlb grumble.. a LOT. The below is from master.today. [12594.640959] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [12594.693000] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [12594.713787] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [12594.743413] nouveau 0000:01:00.0: swiotlb buffer

> Greetings, > > When box is earning its keep, nouveau/swiotlb grumble.. a LOT. The > below is from master.today. > > [12594.640959] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 > bytes) > [12594.693000] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 > bytes) > [12594.713787] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 >

On Thu, 2018-05-10 at 11:10 +0200, Mike Galbraith wrote: > Greetings, > > When box is earning its keep, nouveau/swiotlb grumble.. a LOT. The > below is from master.today. > > [12594.640959] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) > [12594.693000] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) > [12594.713787] nouveau

Split out subsystem specific changes for easier reviews. This will be squashed with main commit. Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com> --- drivers/xen/swiotlb-xen.c | 14 +++++++------- include/xen/swiotlb-xen.h | 12 ++++++------ 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index

Eliminate kernel version checks from i386/kernel/pci-dma.c as a trivial first pass cleanup towards merging. Signed-off-by: Chris Wright <chrisw@osdl.org> --- linux-2.6.11-xen-sparse/arch/xen/i386/kernel/pci-dma.c | 29 ----------------- 1 files changed, 29 deletions(-) ===== arch/xen/i386/kernel/pci-dma.c 1.20 vs edited ===== ---

Hey Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git stable/for-linus-3.13-rc0-tag which has tons of fixes and two major features which are concentrated around the Xen SWIOTLB library. The short <blurb> is that the tracing facility (just one function) has been added to SWIOTLB to make it easier to track I/O progress. Additionally under

On Fri, May 19, 2023 at 01:49:46PM +0100, Andrew Cooper wrote: > > The alternative would be to finally merge swiotlb-xen into swiotlb, in > > which case we might be able to do this later. Let me see what I can > > do there. > > If that is an option, it would be great to reduce the special-cashing. I think it's doable, and I've been wanting it for a while. I just

> +/* > + * Virtio direct mapping DMA API operations structure > + * > + * This defines DMA API structure for all virtio devices which would not > + * either bring in their own DMA OPS from architecture or they would not > + * like to use architecture specific IOMMU based DMA OPS because QEMU > + * expects GPA instead of an IOVA in absence of VIRTIO_F_IOMMU_PLATFORM. > + */

After switching DMA attributes to unsigned long it is easier to just compare the bits. Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com> --- Documentation/DMA-API.txt | 4 +-- arch/arc/mm/dma.c | 4 +-- arch/arm/mm/dma-mapping.c | 36 ++++++++++++-------------- arch/arm/xen/mm.c

Current implementation of DMA API inside virtio core calls device's DMA OPS callback functions when the flag VIRTIO_F_IOMMU_PLATFORM flag is set. But in absence of the flag, virtio core falls back calling basic transformation of the incoming SG addresses as GPA. Going forward virtio should only call DMA API based transformations generating either GPA or IOVA depending on QEMU expectations

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

At the risk of throwing more fuel on the fire, I found the following document on the Microsoft website. It appears to be the file format counterpart to the API documentation presented by Chris Wolf. I'm not familiar with the WAVE format, so I'll let you guys interpret it (or tell me it is irrelevant): http://www.microsoft.com/HWDEV/audio/multichaud.htm [As an aside: Why does Microsoft

Hi, here is the next version of this patch-set. Previous versions can be found here: V1: https://lore.kernel.org/lkml/20190110134433.15672-1-joro at 8bytes.org/ V2: https://lore.kernel.org/lkml/20190115132257.6426-1-joro at 8bytes.org/ V3: https://lore.kernel.org/lkml/20190123163049.24863-1-joro at 8bytes.org/ V4: https://lore.kernel.org/lkml/20190129084342.26030-1-joro at 8bytes.org/

Hi, This is third approach (complete this time) for replacing struct dma_attrs with unsigned long. The main patch (2/45) doing the change is split into many subpatches for easier review (3-43). They should be squashed together when applying. *Important:* Patchset is *only* build tested on allyesconfigs: ARM, ARM64, i386, x86_64 and powerpc. Please provide reviewes and tests for other

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com> CC: konrad.wilk at oracle.com CC: boris.ostrovsky at oracle.com CC: david.vrabel at citrix.com --- drivers/xen/swiotlb-xen.c | 31 ------------------------------- include/xen/swiotlb-xen.h | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 32 insertions(+), 31 deletions(-) diff --git

Hi Konrad, The following patch causes fairly large packet loss when transmitting from dom0 to the physical network, at least with my tg3 hardware, but I assume it can impact anything which uses this interface. I suspect that the issue is that the compound pages allocated in this way are not backed by contiguous mfns and so things fall apart when the driver tries to do DMA. However I