Re: [PATCH v2 1/4] swiotlb-xen: ensure to issue well-formed XENMEM_exchange requests
On Fri, 17 Sep 2021, Jan Beulich wrote:
> While the hypervisor hasn't been enforcing this, we would still better
> avoid issuing requests with GFNs not aligned to the requested order.
> Instead of altering the value also in the call to panic(), drop it
> there for being static and hence easy to determine without being part
> of the panic message.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Stefano Stabellini
> ---
> I question how useful it is to wrap "bytes" in PAGE_ALIGN(), when it is
> a multiple of a segment's size anyway (or at least was supposed to be,
> prior to "swiotlb-xen: maintain slab count properly"). But that's
> perhaps yet another separate patch.
> ---
> v2: Drop logging of alignment. Wrap lines.
>
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -230,10 +230,11 @@ retry:
> /*
>* Get IO TLB memory from any location.
>*/
> - start = memblock_alloc(PAGE_ALIGN(bytes), PAGE_SIZE);
> + start = memblock_alloc(PAGE_ALIGN(bytes),
> +IO_TLB_SEGSIZE << IO_TLB_SHIFT);
> if (!start)
> - panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
> - __func__, PAGE_ALIGN(bytes), PAGE_SIZE);
> + panic("%s: Failed to allocate %lu bytes\n",
> + __func__, PAGE_ALIGN(bytes));
>
> /*
>* And replace that memory with pages under 4GB.
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [GIT PULL] dma-mapping fixes for Linux 5.15 (2nd attempt)
The pull request you sent on Fri, 17 Sep 2021 18:38:52 +0200: > git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.15-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b9b11b133b4a0b4f8dc36ec04d81d630f763eaa6 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[GIT PULL] dma-mapping fixes for Linux 5.15 (2nd attempt)
The following changes since commit c1dec343d7abdf8e71aab2a289ab45ce8b1afb7e: hexagon: use the generic global coherent pool (2021-08-19 09:02:40 +0200) are available in the Git repository at: git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.15-1 for you to fetch changes up to 59583f747664046aaae5588d56d5954fab66cce8: sparc32: page align size in arch_dma_alloc (2021-09-14 14:35:17 +0200) dma-mapping fixes for Linux 5.15 - page align size in sparc32 arch_dma_alloc (Andreas Larsson) - tone down a new dma-debug message (Hamza Mahfooz) - fix the kerneldoc for dma_map_sg_attrs (me) Andreas Larsson (1): sparc32: page align size in arch_dma_alloc Christoph Hellwig (1): dma-mapping: fix the kerneldoc for dma_map_sg_attrs Hamza Mahfooz (1): dma-debug: prevent an error message from causing runtime problems arch/sparc/kernel/ioport.c | 4 +++- kernel/dma/debug.c | 3 ++- kernel/dma/mapping.c | 3 ++- 3 files changed, 7 insertions(+), 3 deletions(-) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [GIT PULL] dma-mapping fixes for Linux 5.15
The pull request you sent on Fri, 17 Sep 2021 13:22:42 +0200: > git://git.infradead.org/nvme.git tags/nvme-5.15-2021-09-15 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/65ed1e692f2b996292a5bd973200442816dd0ec1 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 2/4] PCI: only build xen-pcifront in PV-enabled environments
s/only/Only/ in subject On Fri, Sep 17, 2021 at 12:48:03PM +0200, Jan Beulich wrote: > The driver's module init function, pcifront_init(), invokes > xen_pv_domain() first thing. That construct produces constant "false" > when !CONFIG_XEN_PV. Hence there's no point building the driver in > non-PV configurations. Thanks for these bread crumbs. xen_domain_type is set to XEN_PV_DOMAIN only by xen_start_kernel() in enlighten_pv.c, which is only built when CONFIG_XEN_PV=y, so even I can verify this :) > Drop the (now implicit and generally wrong) X86 dependency: At present, > XEN_PV con only be set when X86 is also enabled. In general an > architecture supporting Xen PV (and PCI) would want to have this driver > built. s/con only/can only/ > Signed-off-by: Jan Beulich > Reviewed-by: Stefano Stabellini Acked-by: Bjorn Helgaas > --- > v2: Title and description redone. > > --- a/drivers/pci/Kconfig > +++ b/drivers/pci/Kconfig > @@ -110,7 +110,7 @@ config PCI_PF_STUB > > config XEN_PCIDEV_FRONTEND > tristate "Xen PCI Frontend" > - depends on X86 && XEN > + depends on XEN_PV > select PCI_XEN > select XEN_XENBUS_FRONTEND > default y > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [GIT PULL] dma-mapping fixes for Linux 5.15
On Fri, Sep 17, 2021 at 4:23 AM Christoph Hellwig wrote: > > nvme fixes for Linux 5.15 This presumably went to the wrong person for the same reason the subject line was bogus. I got these fixes through Jens, if you had an _actual_ dma-mapping branch you wanted me to pull, you did the wrong pull request. Please send that proper one instead. Or, if it was just this nvme thing, it's all sorted out already. Linus ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing
> -Original Message- > From: Jon Nettleton [mailto:j...@solid-run.com] > Sent: 16 September 2021 12:17 > To: Shameerali Kolothum Thodi > Cc: Robin Murphy ; Lorenzo Pieralisi > ; Laurentiu Tudor ; > linux-arm-kernel ; ACPI Devel Maling > List ; Linux IOMMU > ; Joerg Roedel ; Will > Deacon ; wanghuiqiang ; > Guohanjun (Hanjun Guo) ; Steven Price > ; Sami Mujawar ; Eric > Auger ; yangyicong > Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing > > On Thu, Sep 16, 2021 at 10:26 AM Shameerali Kolothum Thodi > wrote: > > > > > > > > > -Original Message- > > > From: Jon Nettleton [mailto:j...@solid-run.com] > > > Sent: 16 September 2021 08:52 > > > To: Shameerali Kolothum Thodi > > > > Cc: Robin Murphy ; Lorenzo Pieralisi > > > ; Laurentiu Tudor > > > ; linux-arm-kernel > > > ; ACPI Devel Maling List > > > ; Linux IOMMU > > > ; Joerg Roedel ; > > > Will Deacon ; wanghuiqiang > > > ; Guohanjun (Hanjun Guo) > > > ; Steven Price ; Sami > > > Mujawar ; Eric Auger > ; > > > yangyicong > > > Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node > > > parsing > > > > > > On Thu, Sep 16, 2021 at 9:26 AM Shameerali Kolothum Thodi > > > wrote: > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Jon Nettleton [mailto:j...@solid-run.com] > > > > > Sent: 06 September 2021 20:51 > > > > > To: Robin Murphy > > > > > Cc: Lorenzo Pieralisi ; Shameerali > > > > > Kolothum Thodi ; Laurentiu > > > > > Tudor ; linux-arm-kernel > > > > > ; ACPI Devel Maling List > > > > > ; Linux IOMMU > > > > > ; Linuxarm > > > > > ; Joerg Roedel ; Will > > > > > Deacon ; wanghuiqiang > > > > > ; Guohanjun (Hanjun Guo) > > > > > ; Steven Price ; > > > > > Sami Mujawar ; Eric Auger > > > ; > > > > > yangyicong > > > > > Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node > > > > > parsing > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > On the prot value assignment based on the remapping flag, > > > > > > > I'd like to hear Robin/Joerg's opinion, I'd avoid being in a > > > > > > > situation where "normally" this would work but then we have > > > > > > > to quirk > > > it. > > > > > > > > > > > > > > Is this a valid assumption _always_ ? > > > > > > > > > > > > No. Certainly applying IOMMU_CACHE without reference to the > > > > > > device's _CCA attribute or how CPUs may be accessing a shared > > > > > > buffer could lead to a loss of coherency. At worst, applying > > > > > > IOMMU_MMIO to a device-private buffer *could* cause the device > > > > > > to lose coherency with itself if the memory underlying the RMR > > > > > > may have allocated into system caches. Note that the expected > > > > > > use for non-remappable RMRs is the device holding some sort of > > > > > > long-lived private data in system RAM - the MSI doorbell trick > > > > > > is far more of a niche > > > hack really. > > > > > > > > > > > > At the very least I think we need to refer to the device's > > > > > > memory access properties here. > > > > > > > > > > > > Jon, Laurentiu - how do RMRs correspond to the EFI memory map > > > > > > on your firmware? I'm starting to think that as long as the > > > > > > underlying memory is described appropriately there then we > > > > > > should be able to infer correct attributes from the EFI memory type > and flags. > > > > > > > > > > The devices are all cache coherent and marked as _CCA, 1. The > > > > > Memory regions are in the virt table as > > > ARM_MEMORY_REGION_ATTRIBUTE_DEVICE. > > > > > > > > > > The current chicken and egg problem we have is that during the > > > > > fsl-mc-bus initialization we call > > > > > > > > > > error = acpi_dma_configure_id(>dev, DEV_DMA_COHERENT, > > > > > _stream_id); > > > > > > > > > > which gets deferred because the SMMU has not been initialized yet. > > > > > Then we initialize the RMR tables but there is no device > > > > > reference there to be able to query device properties, only the stream > id. > > > > > After the IORT tables are parsed and the SMMU is setup, on the > > > > > second device probe we associate everything based on the stream > > > > > id and the fsl-mc-bus device is able to claim its 1-1 DMA mappings. > > > > > > > > Can we solve this order problem by delaying the > > > > iommu_alloc_resv_region() to the > > > > iommu_dma_get_rmr_resv_regions(dev, > > > > list) ? We could invoke > > > > device_get_dma_attr() from there which I believe will return the > > > > _CCA > > > attribute. > > > > > > > > Or is that still early to invoke that? > > > > > > That looks like it should work. Do we then also need to parse > > > through the VirtualMemoryTable matching the start and end addresses > > > to determine the other memory attributes like MMIO? > > > > Yes. But that looks tricky as I can't find that readily available on > > Arm, like the efi_mem_attributes(). I will take a look. > > > > Please let me know if there is one or any other easy
[GIT PULL] dma-mapping fixes for Linux 5.15
The following changes since commit 67f3b2f822b7e71cfc9b42dbd9f3144fa2933e0b: blk-mq: avoid to iterate over stale request (2021-09-12 19:32:43 -0600) are available in the Git repository at: git://git.infradead.org/nvme.git tags/nvme-5.15-2021-09-15 for you to fetch changes up to 70f437fb4395ad4d1d16fab9a1ad9fbc9fc0579b: nvme-tcp: fix io_work priority inversion (2021-09-14 10:32:05 +0200) nvme fixes for Linux 5.15 - fix ANA state updates when a namespace is not present (Anton Eidelman) - nvmet: fix a width vs precision bug in nvmet_subsys_attr_serial_show (Dan Carpenter) - avoid race in shutdown namespace removal (Daniel Wagner) - fix io_work priority inversion in nvme-tcp (Keith Busch) - destroy cm id before destroy qp to avoid use after free (Ruozhu Li) Anton Eidelman (1): nvme-multipath: fix ANA state updates when a namespace is not present Dan Carpenter (1): nvmet: fix a width vs precision bug in nvmet_subsys_attr_serial_show() Daniel Wagner (1): nvme: avoid race in shutdown namespace removal Keith Busch (1): nvme-tcp: fix io_work priority inversion Ruozhu Li (1): nvme-rdma: destroy cm id before destroy qp to avoid use after free drivers/nvme/host/core.c | 15 +++ drivers/nvme/host/multipath.c | 7 +-- drivers/nvme/host/rdma.c | 16 +++- drivers/nvme/host/tcp.c| 20 ++-- drivers/nvme/target/configfs.c | 2 +- 5 files changed, 26 insertions(+), 34 deletions(-) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] swiotlb: set IO TLB segment size via cmdline
Hi Jan, >>> In order to be sure to catch all uses like this one (including ones >>> which make it upstream in parallel to yours), I think you will want >>> to rename the original IO_TLB_SEGSIZE to e.g. IO_TLB_DEFAULT_SEGSIZE. >> >> I don't understand your point. Can you clarify this? > > There's a concrete present example: I have a patch pending adding > another use of IO_TLB_SEGSIZE. This use would need to be replaced > like you do here in several places. The need for the additional > replacement would be quite obvious (from a build failure) if you > renamed the manifest constant. Without renaming, it'll take > someone running into an issue on a live system, which I consider > far worse. This is because a simple re-basing of one of the > patches on top of the other will not point out the need for the > extra replacement, nor would a test build (with both patches in > place). It's reasonable. I will change the original IO_TLB_SEGSIZE to IO_TLB_DEFAULT_SEGSIZE in the next patch series. Thanks. ср, 15 сент. 2021 г. в 16:50, Jan Beulich : > > On 15.09.2021 15:37, Roman Skakun wrote: > >>> From: Roman Skakun > >>> > >>> It is possible when default IO TLB size is not > >>> enough to fit a long buffers as described here [1]. > >>> > >>> This patch makes a way to set this parameter > >>> using cmdline instead of recompiling a kernel. > >>> > >>> [1] https://www.xilinx.com/support/answers/72694.html > >> > >> I'm not convinced the swiotlb use describe there falls under "intended > >> use" - mapping a 1280x720 framebuffer in a single chunk? > > > > I had the same issue while mapping DMA chuck ~4MB for gem fb when > > using xen vdispl. > > I got the next log: > > [ 142.030421] rcar-fcp fea2f000.fcp: swiotlb buffer is full (sz: > > 3686400 bytes), total 32768 (slots), used 32 (slots) > > > > It happened when I tried to map bounce buffer, which has a large size. > > The default size if 128(IO_TLB_SEGSIZE) * 2048(IO_TLB_SHIFT) = 262144 > > bytes, but we requested 3686400 bytes. > > When I change IO_TLB_SEGSIZE to 2048. (2048(IO_TLB_SEGSIZE) * > > 2048(IO_TLB_SHIFT) = 4194304bytes). > > It makes possible to retrieve a bounce buffer for requested size. > > After changing this value, the problem is gone. > > But the question remains: Why does the framebuffer need to be mapped > in a single giant chunk? > > >> In order to be sure to catch all uses like this one (including ones > >> which make it upstream in parallel to yours), I think you will want > >> to rename the original IO_TLB_SEGSIZE to e.g. IO_TLB_DEFAULT_SEGSIZE. > > > > I don't understand your point. Can you clarify this? > > There's a concrete present example: I have a patch pending adding > another use of IO_TLB_SEGSIZE. This use would need to be replaced > like you do here in several places. The need for the additional > replacement would be quite obvious (from a build failure) if you > renamed the manifest constant. Without renaming, it'll take > someone running into an issue on a live system, which I consider > far worse. This is because a simple re-basing of one of the > patches on top of the other will not point out the need for the > extra replacement, nor would a test build (with both patches in > place). > > Jan > -- Best Regards, Roman. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 4/4] swiotlb-xen: this is PV-only on x86
The code is unreachable for HVM or PVH, and it also makes little sense
in auto-translated environments. On Arm, with
xen_{create,destroy}_contiguous_region() both being stubs, I have a hard
time seeing what good the Xen specific variant does - the generic one
ought to be fine for all purposes there. Still Arm code explicitly
references symbols here, so the code will continue to be included there.
Instead of making PCI_XEN's "select" conditional, simply drop it -
SWIOTLB_XEN will be available unconditionally in the PV case anyway, and
is - as explained above - dead code in non-PV environments.
This in turn allows dropping the stubs for
xen_{create,destroy}_contiguous_region(), the former of which was broken
anyway - it failed to set the DMA handle output.
Signed-off-by: Jan Beulich
Reviewed-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2605,7 +2605,6 @@ config PCI_OLPC
config PCI_XEN
def_bool y
depends on PCI && XEN
- select SWIOTLB_XEN
config MMCONF_FAM10H
def_bool y
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -177,6 +177,7 @@ config XEN_GRANT_DMA_ALLOC
config SWIOTLB_XEN
def_bool y
+ depends on XEN_PV || ARM || ARM64
select DMA_OPS
select SWIOTLB
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -46,19 +46,7 @@ extern unsigned long *xen_contiguous_bit
int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
unsigned int address_bits,
dma_addr_t *dma_handle);
-
void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order);
-#else
-static inline int xen_create_contiguous_region(phys_addr_t pstart,
- unsigned int order,
- unsigned int address_bits,
- dma_addr_t *dma_handle)
-{
- return 0;
-}
-
-static inline void xen_destroy_contiguous_region(phys_addr_t pstart,
-unsigned int order) { }
#endif
#if defined(CONFIG_XEN_PV)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 3/4] xen/pci-swiotlb: reduce visibility of symbols
xen_swiotlb and pci_xen_swiotlb_init() are only used within the file
defining them, so make them static and remove the stubs. Otoh
pci_xen_swiotlb_detect() has a use (as function pointer) from the main
pci-swiotlb.c file - convert its stub to a #define to NULL.
Signed-off-by: Jan Beulich
Reviewed-by: Christoph Hellwig
--- a/arch/x86/include/asm/xen/swiotlb-xen.h
+++ b/arch/x86/include/asm/xen/swiotlb-xen.h
@@ -3,14 +3,10 @@
#define _ASM_X86_SWIOTLB_XEN_H
#ifdef CONFIG_SWIOTLB_XEN
-extern int xen_swiotlb;
extern int __init pci_xen_swiotlb_detect(void);
-extern void __init pci_xen_swiotlb_init(void);
extern int pci_xen_swiotlb_init_late(void);
#else
-#define xen_swiotlb (0)
-static inline int __init pci_xen_swiotlb_detect(void) { return 0; }
-static inline void __init pci_xen_swiotlb_init(void) { }
+#define pci_xen_swiotlb_detect NULL
static inline int pci_xen_swiotlb_init_late(void) { return -ENXIO; }
#endif
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -18,7 +18,7 @@
#endif
#include
-int xen_swiotlb __read_mostly;
+static int xen_swiotlb __read_mostly;
/*
* pci_xen_swiotlb_detect - set xen_swiotlb to 1 if necessary
@@ -56,7 +56,7 @@ int __init pci_xen_swiotlb_detect(void)
return xen_swiotlb;
}
-void __init pci_xen_swiotlb_init(void)
+static void __init pci_xen_swiotlb_init(void)
{
if (xen_swiotlb) {
xen_swiotlb_init_early();
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 2/4] PCI: only build xen-pcifront in PV-enabled environments
The driver's module init function, pcifront_init(), invokes xen_pv_domain() first thing. That construct produces constant "false" when !CONFIG_XEN_PV. Hence there's no point building the driver in non-PV configurations. Drop the (now implicit and generally wrong) X86 dependency: At present, XEN_PV con only be set when X86 is also enabled. In general an architecture supporting Xen PV (and PCI) would want to have this driver built. Signed-off-by: Jan Beulich Reviewed-by: Stefano Stabellini --- v2: Title and description redone. --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -110,7 +110,7 @@ config PCI_PF_STUB config XEN_PCIDEV_FRONTEND tristate "Xen PCI Frontend" - depends on X86 && XEN + depends on XEN_PV select PCI_XEN select XEN_XENBUS_FRONTEND default y ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 1/4] swiotlb-xen: ensure to issue well-formed XENMEM_exchange requests
While the hypervisor hasn't been enforcing this, we would still better
avoid issuing requests with GFNs not aligned to the requested order.
Instead of altering the value also in the call to panic(), drop it
there for being static and hence easy to determine without being part
of the panic message.
Signed-off-by: Jan Beulich
---
I question how useful it is to wrap "bytes" in PAGE_ALIGN(), when it is
a multiple of a segment's size anyway (or at least was supposed to be,
prior to "swiotlb-xen: maintain slab count properly"). But that's
perhaps yet another separate patch.
---
v2: Drop logging of alignment. Wrap lines.
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -230,10 +230,11 @@ retry:
/*
* Get IO TLB memory from any location.
*/
- start = memblock_alloc(PAGE_ALIGN(bytes), PAGE_SIZE);
+ start = memblock_alloc(PAGE_ALIGN(bytes),
+ IO_TLB_SEGSIZE << IO_TLB_SHIFT);
if (!start)
- panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
- __func__, PAGE_ALIGN(bytes), PAGE_SIZE);
+ panic("%s: Failed to allocate %lu bytes\n",
+ __func__, PAGE_ALIGN(bytes));
/*
* And replace that memory with pages under 4GB.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 0/4] swiotlb-xen: remaining fixes and adjustments
The primary intention really was the last patch, there you go (on top of what is already in xen/tip.git for-linus-5.15) ... 1: swiotlb-xen: ensure to issue well-formed XENMEM_exchange requests 2: PCI: only build xen-pcifront in PV-enabled environments 3: xen/pci-swiotlb: reduce visibility of symbols 4: swiotlb-xen: this is PV-only on x86 Jan ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] swiotlb: set IO TLB segment size via cmdline
On 17.09.2021 11:36, Roman Skakun wrote: > I use Xen PV display. In my case, PV display backend(Dom0) allocates > contiguous buffer via DMA-API to > to implement zero-copy between Dom0 and DomU. Why does the buffer need to be allocated by Dom0? If it was allocated by DomU, it could use grants to give the backend direct (zero-copy) access. Jan ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] swiotlb: set IO TLB segment size via cmdline
On 2021-09-17 10:36, Roman Skakun wrote: Hi, Christoph I use Xen PV display. In my case, PV display backend(Dom0) allocates contiguous buffer via DMA-API to to implement zero-copy between Dom0 and DomU. Well, something's gone badly wrong there - if you have to shadow the entire thing in a bounce buffer to import it then it's hardly zero-copy, is it? If you want to do buffer sharing the buffer really needs to be allocated appropriately to begin with, such that all relevant devices can access it directly. That might be something which needs fixing in Xen. Robin. When I start Weston under DomU, I got the next log in Dom0: ``` [ 112.554471] CPU: 0 PID: 367 Comm: weston Tainted: G O 5.10.0-yocto-standard+ #312 [ 112.575149] Call trace: [ 112.577666] dump_backtrace+0x0/0x1b0 [ 112.581373] show_stack+0x18/0x70 [ 112.584746] dump_stack+0xd0/0x12c [ 112.588200] swiotlb_tbl_map_single+0x234/0x360 [ 112.592781] xen_swiotlb_map_page+0xe4/0x4c0 [ 112.597095] xen_swiotlb_map_sg+0x84/0x12c [ 112.601249] dma_map_sg_attrs+0x54/0x60 [ 112.605138] vsp1_du_map_sg+0x30/0x60 [ 112.608851] rcar_du_vsp_map_fb+0x134/0x170 [ 112.613082] rcar_du_vsp_plane_prepare_fb+0x44/0x64 [ 112.618007] drm_atomic_helper_prepare_planes+0xac/0x160 [ 112.623362] drm_atomic_helper_commit+0x88/0x390 [ 112.628029] drm_atomic_nonblocking_commit+0x4c/0x60 [ 112.633043] drm_mode_atomic_ioctl+0x9a8/0xb0c [ 112.637532] drm_ioctl_kernel+0xc4/0x11c [ 112.641506] drm_ioctl+0x21c/0x460 [ 112.644967] __arm64_sys_ioctl+0xa8/0xf0 [ 112.648939] el0_svc_common.constprop.0+0x78/0x1a0 [ 112.653775] do_el0_svc+0x24/0x90 [ 112.657148] el0_svc+0x14/0x20 [ 112.660254] el0_sync_handler+0x1a4/0x1b0 [ 112.664315] el0_sync+0x174/0x180 [ 112.668145] rcar-fcp fea2f000.fcp: swiotlb buffer is full (sz: 3686400 bytes), total 65536 (slots), used 112 (slots) ``` The problem is happened here: https://elixir.bootlin.com/linux/v5.14.4/source/drivers/gpu/drm/rcar-du/rcar_du_vsp.c#L202 Sgt was created in dma_get_sgtable() by dma_common_get_sgtable() and includes a single page chunk as shown here: https://elixir.bootlin.com/linux/v5.14.5/source/kernel/dma/ops_helpers.c#L18 After creating a new sgt, we tried to map this sgt through vsp1_du_map_sg(). Internally, vsp1_du_map_sg() using ops->map_sg (e.g xen_swiotlb_map_sg) to perform mapping. I realized that required segment is too big to be fitted to default swiotlb segment and condition https://elixir.bootlin.com/linux/latest/source/kernel/dma/swiotlb.c#L474 is always false. I know that I use a large buffer, but why can't I map this buffer in one chunk? Thanks! ср, 15 сент. 2021 г. в 16:53, Christoph Hellwig : On Wed, Sep 15, 2021 at 03:49:52PM +0200, Jan Beulich wrote: But the question remains: Why does the framebuffer need to be mapped in a single giant chunk? More importantly: if you use dynamic dma mappings for your framebuffer you're doing something wrong. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] swiotlb: set IO TLB segment size via cmdline
Hi, Christoph I use Xen PV display. In my case, PV display backend(Dom0) allocates contiguous buffer via DMA-API to to implement zero-copy between Dom0 and DomU. When I start Weston under DomU, I got the next log in Dom0: ``` [ 112.554471] CPU: 0 PID: 367 Comm: weston Tainted: G O 5.10.0-yocto-standard+ #312 [ 112.575149] Call trace: [ 112.577666] dump_backtrace+0x0/0x1b0 [ 112.581373] show_stack+0x18/0x70 [ 112.584746] dump_stack+0xd0/0x12c [ 112.588200] swiotlb_tbl_map_single+0x234/0x360 [ 112.592781] xen_swiotlb_map_page+0xe4/0x4c0 [ 112.597095] xen_swiotlb_map_sg+0x84/0x12c [ 112.601249] dma_map_sg_attrs+0x54/0x60 [ 112.605138] vsp1_du_map_sg+0x30/0x60 [ 112.608851] rcar_du_vsp_map_fb+0x134/0x170 [ 112.613082] rcar_du_vsp_plane_prepare_fb+0x44/0x64 [ 112.618007] drm_atomic_helper_prepare_planes+0xac/0x160 [ 112.623362] drm_atomic_helper_commit+0x88/0x390 [ 112.628029] drm_atomic_nonblocking_commit+0x4c/0x60 [ 112.633043] drm_mode_atomic_ioctl+0x9a8/0xb0c [ 112.637532] drm_ioctl_kernel+0xc4/0x11c [ 112.641506] drm_ioctl+0x21c/0x460 [ 112.644967] __arm64_sys_ioctl+0xa8/0xf0 [ 112.648939] el0_svc_common.constprop.0+0x78/0x1a0 [ 112.653775] do_el0_svc+0x24/0x90 [ 112.657148] el0_svc+0x14/0x20 [ 112.660254] el0_sync_handler+0x1a4/0x1b0 [ 112.664315] el0_sync+0x174/0x180 [ 112.668145] rcar-fcp fea2f000.fcp: swiotlb buffer is full (sz: 3686400 bytes), total 65536 (slots), used 112 (slots) ``` The problem is happened here: https://elixir.bootlin.com/linux/v5.14.4/source/drivers/gpu/drm/rcar-du/rcar_du_vsp.c#L202 Sgt was created in dma_get_sgtable() by dma_common_get_sgtable() and includes a single page chunk as shown here: https://elixir.bootlin.com/linux/v5.14.5/source/kernel/dma/ops_helpers.c#L18 After creating a new sgt, we tried to map this sgt through vsp1_du_map_sg(). Internally, vsp1_du_map_sg() using ops->map_sg (e.g xen_swiotlb_map_sg) to perform mapping. I realized that required segment is too big to be fitted to default swiotlb segment and condition https://elixir.bootlin.com/linux/latest/source/kernel/dma/swiotlb.c#L474 is always false. I know that I use a large buffer, but why can't I map this buffer in one chunk? Thanks! ср, 15 сент. 2021 г. в 16:53, Christoph Hellwig : > > On Wed, Sep 15, 2021 at 03:49:52PM +0200, Jan Beulich wrote: > > But the question remains: Why does the framebuffer need to be mapped > > in a single giant chunk? > > More importantly: if you use dynamic dma mappings for your framebuffer > you're doing something wrong. -- Best Regards, Roman. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
