linux-kernel - Re: [PATCH] arm/mm: add option to prefer IOMMU ops for DMA on Xen

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 14 Nov 2023 13:47:25 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Chuck Zmudzinski <brchuckz@....com>,
        linux-arm-kernel@...ts.infradead.org
Cc:     Russell King <linux@...linux.org.uk>,
        Juergen Gross <jgross@...e.com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>,
        linux-kernel@...r.kernel.org, xen-devel@...ts.xenproject.org,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Jason Gunthorpe <jgg@...pe.ca>, Arnd Bergmann <arnd@...db.de>,
        Julien Grall <julien@....org>,
        Mario Marietto <marietto2008@...il.com>,
        Bertrand Marquis <bertrand.marquis@....com>
Subject: Re: [PATCH] arm/mm: add option to prefer IOMMU ops for DMA on Xen

On 11/11/2023 6:45 pm, Chuck Zmudzinski wrote:
> Enabling the new option, ARM_DMA_USE_IOMMU_XEN, fixes this error when
> attaching the Exynos mixer in Linux dom0 on Xen on the Chromebook Snow
> (and probably on other devices that use the Exynos mixer):
> 
> [drm] Exynos DRM: using 14400000.fimd device for DMA mapping operations
> exynos-drm exynos-drm: bound 14400000.fimd (ops 0xc0d96354)
> exynos-mixer 14450000.mixer: [drm:exynos_drm_register_dma] *ERROR* Device
>                               14450000.mixer lacks support for IOMMU
> exynos-drm exynos-drm: failed to bind 14450000.mixer (ops 0xc0d97554): -22
> exynos-drm exynos-drm: adev bind failed: -22
> exynos-dp: probe of 145b0000.dp-controller failed with error -22
> 
> Linux normally uses xen_swiotlb_dma_ops for DMA for all devices when
> xen_swiotlb is detected even when Xen exposes an IOMMU to Linux. Enabling
> the new config option allows devices such as the Exynos mixer to use the
> IOMMU instead of xen_swiotlb_dma_ops for DMA and this fixes the error.
> 
> The new config option is not set by default because it is likely some
> devices that use IOMMU for DMA on Xen will cause DMA errors and memory
> corruption when Xen PV block and network drivers are in use on the system.
> 
> Link: https://lore.kernel.org/xen-devel/acfab1c5-eed1-4930-8c70-8681e256c820@netscape.net/
> 
> Signed-off-by: Chuck Zmudzinski <brchuckz@....com>
> ---
> The reported error with the Exynos mixer is not fixed by default by adding
> a second patch to select the new option in the Kconfig definition for the
> Exynos mixer if EXYNOS_IOMMU and SWIOTLB_XEN are enabled because it is
> not certain setting the config option is suitable for all cases. So it is
> necessary to explicitly select the new config option during the config
> stage of the Linux kernel build to fix the reported error or similar
> errors that have the same cause of lack of support for IOMMU on Xen. This
> is necessary to avoid any regressions that might be caused by enabling the
> new option by default for the Exynos mixer.
>   arch/arm/mm/dma-mapping.c |  6 ++++++
>   drivers/xen/Kconfig       | 16 ++++++++++++++++
>   2 files changed, 22 insertions(+)
> 
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 5409225b4abc..ca04fdf01be3 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1779,6 +1779,12 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>   	if (iommu)
>   		arm_setup_iommu_dma_ops(dev, dma_base, size, iommu, coherent);
>   
> +#ifdef CONFIG_ARM_DMA_USE_IOMMU_XEN

FWIW I don't think this really needs a config option - if Xen *has* made 
an IOMMU available, then there isn't really much reason not to use it, 
and if for some reason someone really didn't want to then they could 
simply disable the IOMMU driver anyway.

> +	if (dev->dma_ops == &iommu_ops) {
> +		dev->archdata.dma_ops_setup = true;

The existing assignment is effectively unconditional by this point 
anyway, so could probably just be moved earlier to save duplicating it 
(or perhaps just make the xen_setup_dma_ops() call conditional instead 
to save the early return as well).

However, are the IOMMU DMA ops really compatible with Xen? The comments 
about hypercalls and foreign memory in xen_arch_need_swiotlb() leave me 
concerned that assuming non-coherent DMA to any old Dom0 page is OK 
might not actually work in general :/

Thanks,
Robin.

> +		return;
> +	}
> +#endif
>   	xen_setup_dma_ops(dev);
>   	dev->archdata.dma_ops_setup = true;
>   }
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d5989871dd5d..44e1334b6acd 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -181,6 +181,22 @@ config SWIOTLB_XEN
>   	select DMA_OPS
>   	select SWIOTLB
>   
> +config ARM_DMA_USE_IOMMU_XEN
> +	bool "Prefer IOMMU DMA ops on Xen"
> +	depends on SWIOTLB_XEN
> +	depends on ARM_DMA_USE_IOMMU
> +	help
> +	  Normally on Xen, the IOMMU is used by Xen and not exposed to
> +	  Linux. Some Arm systems such as Exynos have an IOMMU that
> +	  Xen does not use so the IOMMU is exposed to Linux in those
> +	  cases. This option enables Linux to use the IOMMU instead of
> +	  using the Xen swiotlb_dma_ops for DMA on Xen.
> +
> +	  Say N here unless support for one or more devices that use
> +	  IOMMU ops instead of Xen swiotlb ops for DMA is needed and the
> +	  devices that use the IOMMU do not cause any problems on the
> +	  Xen system in use.
> +
>   config XEN_PCI_STUB
>   	bool
>