Received-SPF: pass (google.com: domain of linux-kernel+bounces-170227-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240503183527.1548119-1-tjmercier@google.com> <20240504101651.7de5106f@meshulam.tesarici.cz>
In-Reply-To: <20240504101651.7de5106f@meshulam.tesarici.cz>
From: "T.J. Mercier" <tjmercier@google.com>
Date: Mon, 6 May 2024 10:22:50 -0700
Message-ID: <CABdmKX06v23-w8PQJab8kgfPDRYLU3bQSQ4AsC3zrzxYL955gQ@mail.gmail.com>
Subject: Re: [PATCH] swiotlb: iommu/dma: Clarify swiotlb options apply only to dma-direct
To: =?UTF-8?B?UGV0ciBUZXNhxZnDrWs=?= <petr@tesarici.cz>
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, May 4, 2024 at 1:16=E2=80=AFAM Petr Tesa=C5=99=C3=ADk <petr@tesaric=
i.cz> wrote:
>
> 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.marina=
s@arm.com
> > [2] https://lore.kernel.org/all/20190906061452.30791-1-baolu.lu@linux.i=
ntel.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/Document=
ation/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 th=
ey
> >                                wouldn't be automatically used by the ke=
rnel
> > +                              where a hardware IOMMU is not involved
> >                       noforce -- Never use bounce buffers (for debuggin=
g)
> >
> >       switches=3D       [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/Documenta=
tion/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 hardwar=
e 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=3D<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=3D<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

Thanks. I think I should also update the commit message:
"The swiotlb=3Dforce kernel command line parameter does not impact IOMMU
related use of SWIOTLB"
and title:
"Clarify swiotlb=3Dforce option applies only to dma-direct"

As for fixing boot-options.txt, I think it makes the most sense to
expand on just the force option rather than the section summary like
above:
       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