linux-kernel - Re: [PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"

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] [day] [month] [year] [list]

Message-ID: <CALHNRZ-rArVkbEaiEVwMevfbu0dgX5P-ooVYTd-3RHvrhOJ5vQ@mail.gmail.com>
Date: Mon, 3 Nov 2025 12:05:25 -0600
From: Aaron Kling <webgeek1234@...il.com>
To: Thierry Reding <thierry.reding@...il.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Jonathan Hunter <jonathanh@...dia.com>, devicetree@...r.kernel.org, 
	linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"

On Mon, Nov 3, 2025 at 5:07 AM Thierry Reding <thierry.reding@...il.com> wrote:
>
> On Sat, Nov 01, 2025 at 06:13:26PM -0500, Aaron Kling wrote:
> > On Sat, Nov 1, 2025 at 6:01 PM Aaron Kling via B4 Relay
> > <devnull+webgeek1234.gmail.com@...nel.org> wrote:
> > >
> > > From: Aaron Kling <webgeek1234@...il.com>
> > >
> > > This reverts commit ebea268ea583ba4970df425dfef8c8e21d0a4e12.
> > >
> > > Mmu is now being enabled for the display controllers.
> > >
> > > Signed-off-by: Aaron Kling <webgeek1234@...il.com>
> > > ---
> > >  arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > index 1399342f23e1c4f73b278adc66dfb948fc30d326..854ed6d46aa1d8eedcdfbae1fdde1374adf40337 100644
> > > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > @@ -1807,7 +1807,7 @@ iommu@...00000 {
> > >                         #iommu-cells = <1>;
> > >
> > >                         nvidia,memory-controller = <&mc>;
> > > -                       status = "disabled";
> > > +                       status = "okay";
> > >                 };
> > >
> > >                 smmu: iommu@...00000 {
> > >
> > > --
> > > 2.51.0
> > >
> > >
> >
> > Question for Jon as the author of the commit being reverted. The
> > commit message states "we do not have a way to pass frame-buffer
> > memory from the bootloader to the kernel". If I understand this
> > correctly, this is talking about seamless handoff. What does this have
> > to do with enabling mmu on the display controllers? Seamless does not
> > work on any tegra arch as far as I'm aware, but Tegra194 is the only
> > one that doesn't have mmu enabled for the dc's. But enabling mmu
> > allows for better and faster memory allocation. My initial attempts to
> > enable this didn't work because I tried to attach them to the main mmu
> > unit, see the related freedesktop issue [0]. After noticing in the
> > downstream dt that the dc's are on a separate unit, I made it work.
> > And so far, it seems to work just as well as Tegra186. Then when I was
> > packaging up the change to submit, I found that this had been
> > explicitly disabled. But I'm not seeing why. Am I missing some
> > additional factors?
>
> This isn't seamless handoff to the Tegra DRM driver for display, but
> rather to simple-framebuffer. While this does technically work, it also
> causes a spew of SMMU faults during early boot because the firmware does
> not properly pass the SMMU mapping information to the kernel.
>
> In a nutshell what happens is that the firmware sets up the display
> controller to scan out from a reserved memory region, but it does so
> without involving the SMMU, so it uses physical addresses directly. When
> the kernel boots and the SMMU is enabled the continued accesses from
> display hardware cause SMMU faults (because there is no mapping for the
> framebuffer addresses).
>
> That said, we did solve these issues and this may not be happening
> anymore with the most recent L4T releases, so it may be okay to revert
> this now. We should find out exactly which release includes all the
> needed changes so that it can be referenced in the commit message. I
> want to avoid people running new kernels with an old L4T release and
> then seeing these errors without any reference as to why that might
> suddenly happen.

For reference, I have rolled back my Android usecase to use the L4T
r32.7.6 bootloaders on T194 for a variety of reasons. So I am using
cboot as the final bootloader and not edk2 as in L4T r34/r35. I have a
pending cboot patch to support simple-framebuffer handoff, but haven't
fully verified it as tegra-drm is currently unable to takeover from
simplefb like openrm does for t234. But all that to say that since I
no longer use r35 for t194 I don't have the setup to easily verify
which point release works here and what doesn't.

Aaron