[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240509075212.33e521a8@meshulam.tesarici.cz>
Date: Thu, 9 May 2024 07:52:12 +0200
From: Petr Tesařík <petr@...arici.cz>
To: "T.J. Mercier" <tjmercier@...gle.com>
Cc: Jonathan Corbet <corbet@....net>, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen
<dave.hansen@...ux.intel.com>, x86@...nel.org, "H. Peter Anvin"
<hpa@...or.com>, mhklinux@...look.com, robin.murphy@....com,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] doc: swiotlb: iommu/dma: Clarify swiotlb=force
option applies only to dma-direct
On Tue, 7 May 2024 01:34:58 +0000
"T.J. Mercier" <tjmercier@...gle.com> wrote:
> IOMMU implementations now sometimes bounce memory through SWIOTLB to
> achieve cacheline alignment [1], or prevent DMA attacks by untrusted
> devices [2]. These uses of SWIOTLB differ conceptually from historical
> use which was a solution to the problem of device addressing
> limitations that prevent DMA to some portion of system memory
> (typically beyond 4 GiB). IOMMUs also solve the problem of device
> addressing limitations and therefore eliminate the need for SWIOTLB for
> that purpose. However as mentioned, IOMMUs can use SWIOTLB for other
> purposes.
>
> The swiotlb=force kernel command line parameter does not impact IOMMU
> related use of SWIOTLB, and that is intentional. IOMMUs cannot be forced
> to use SWIOTLB for all buffers. Update the documentation for the swiotlb
> parameter to clarify that SWIOTLB use can only be forced in scenarios
> where an IOMMU is not involved.
>
> [1] https://lore.kernel.org/all/20230612153201.554742-16-catalin.marinas@arm.com
> [2] https://lore.kernel.org/all/20190906061452.30791-1-baolu.lu@linux.intel.com/
> Signed-off-by: T.J. Mercier <tjmercier@...gle.com>
Looks good to me now.
Reviewed-by: Petr Tesarik <petr@...arici.cz>
Petr T
> ---
> Documentation/admin-guide/kernel-parameters.txt | 1 +
> Documentation/arch/x86/x86_64/boot-options.rst | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 213d0719e2b7..84c582ac246c 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -6486,6 +6486,7 @@
> to a power of 2.
> force -- force using of bounce buffers even if they
> wouldn't be automatically used by the kernel
> + where a hardware IOMMU is not involved
> noforce -- Never use bounce buffers (for debugging)
>
> switches= [HW,M68k,EARLY]
> diff --git a/Documentation/arch/x86/x86_64/boot-options.rst b/Documentation/arch/x86/x86_64/boot-options.rst
> index 137432d34109..a37139d1752f 100644
> --- a/Documentation/arch/x86/x86_64/boot-options.rst
> +++ b/Documentation/arch/x86/x86_64/boot-options.rst
> @@ -292,6 +292,9 @@ implementation:
> Prereserve that many 2K slots for the software IO bounce buffering.
> force
> Force all IO through the software TLB.
> + Hardware IOMMU implementations can use SWIOTLB bounce buffering in
> + some circumstances, but they cannot be forced to always use them, so
> + this option only has an effect when no hardware IOMMU is involved.
> noforce
> Do not initialize the software TLB.
>
Powered by blists - more mailing lists