Received-SPF: pass (google.com: domain of linux-kernel+bounces-168551-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Sat, 4 May 2024 10:16:51 +0200
From: Petr =?UTF-8?B?VGVzYcWZw61r?= <petr@tesarici.cz>
To: "T.J. Mercier" <tjmercier@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>, Thomas Gleixner <tglx@linutronix.de>,
 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen
 <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"
 <hpa@zytor.com>, hch@infradead.org, robin.murphy@arm.com, joro@8bytes.org,
 will@kernel.org, akpm@linux-foundation.org, isaacmanjarres@google.com,
 iommu@lists.linux.dev, linux-doc@vger.kernel.org,
 linux-kernel@vger.kernel.org, Michael Kelley <mhklinux@outlook.com>
Subject: Re: [PATCH] swiotlb: iommu/dma: Clarify swiotlb options apply only
 to dma-direct
Message-ID: <20240504101651.7de5106f@meshulam.tesarici.cz>
In-Reply-To: <20240503183527.1548119-1-tjmercier@google.com>
References: <20240503183527.1548119-1-tjmercier@google.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri,  3 May 2024 18:35:26 +0000
"T.J. Mercier" <tjmercier@google.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 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@google.com>
> ---
>  Documentation/admin-guide/kernel-parameters.txt | 1 +
>  Documentation/arch/x86/x86_64/boot-options.rst  | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> 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]

Yes, this part is correct. SWIOTLB cannot be forced if there is an IOMMU.

> diff --git a/Documentation/arch/x86/x86_64/boot-options.rst b/Documentation/arch/x86/x86_64/boot-options.rst
> index 137432d34109..066b4bc81583 100644
> --- a/Documentation/arch/x86/x86_64/boot-options.rst
> +++ b/Documentation/arch/x86/x86_64/boot-options.rst
> @@ -285,7 +285,7 @@ iommu options only relevant to the AMD GART hardware IOMMU:
>        Always panic when IOMMU overflows.
>  
>  iommu options only relevant to the software bounce buffering (SWIOTLB) IOMMU
> -implementation:
> +implementation where a hardware IOMMU is not involved:
>  
>      swiotlb=<slots>[,force,noforce]
>        <slots>

But this part needs some improvement. The "swiotlb" option is not
entirely ignored if there is a hardware IOMMU. For example, the size of
the SWIOTLB can be adjusted using "swiotlb=<slots>", and since SWIOTLB
can be used by IOMMUs for other purposes (as you correctly note in the
commit message), this setting is relevant even where a hardware IOMMU
is involved.

Petr T