Date: Tue, 30 Jun 2026 14:51:40 +0000
From: Pranjal Shrivastava <praan@google.com>
To: Mostafa Saleh <smostafa@google.com>
Cc: Nicolin Chen <nicolinc@nvidia.com>, will@kernel.org,
	robin.murphy@arm.com, jgg@nvidia.com, joro@8bytes.org,
	kees@kernel.org, baolu.lu@linux.intel.com, kevin.tian@intel.com,
	miko.lenczewski@arm.com, linux-arm-kernel@lists.infradead.org,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, jamien@nvidia.com
Subject: Re: [PATCH rc v7 0/7] iommu/arm-smmu-v3: Fix device crash on kdump
 kernel
Message-ID: <akPX_N0P2EcI_jbV@google.com>
References: <cover.1782799827.git.nicolinc@nvidia.com>
 <akPB6l-fuJUcg4a2@google.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <akPB6l-fuJUcg4a2@google.com>

On Tue, Jun 30, 2026 at 01:17:30PM +0000, Mostafa Saleh wrote:
> On Mon, Jun 29, 2026 at 11:15:33PM -0700, Nicolin Chen wrote:
> > When transitioning to a kdump kernel, the primary kernel might have crashed
> > while endpoint devices were actively bus-mastering DMA. Currently, the SMMU
> > driver aggressively resets the hardware during probe by clearing CR0_SMMUEN
> > and setting the Global Bypass Attribute (GBPA) to ABORT.
> > 
> > In a kdump scenario, this aggressive reset is highly destructive:
> > a) If GBPA is set to ABORT, in-flight DMA will be aborted, generating fatal
> >    PCIe AER or SErrors that may panic the kdump kernel
> 
> Can you please clarify more on those errors, what conditions will
> trigger that?
> For example, patch 4 disables the EVTQ to avoid events as there might
> be a lot, why are they not fatal also?
> 
> > b) If GBPA is set to BYPASS, in-flight DMA targeting some IOVAs will bypass
> >    the SMMU and corrupt the physical memory at those 1:1 mapped IOVAs.
> > 
> > To safely absorb in-flight DMA, the kdump kernel must leave SMMUEN=1 intact
> > and avoid modifying STRTAB_BASE. This allows HW to continue translating in-
> > flight DMA using the crashed kernel's page tables until the endpoint device
> > drivers probe and quiesce their respective hardware.
> > 
> > However, the ARM SMMUv3 architecture specification states that updating the
> > SMMU_STRTAB_BASE register while SMMUEN == 1 is UNPREDICTABLE or ignored.
> > 
> > This leaves a kdump kernel no choice but to adopt the stream table from the
> > crashed kernel.
> 
> In many cases the patches assume that the CDs/STE might be corrupted,
> but still attempt to retrieve them with some validation
> (log2size/split...)
> However, the base address might be broken, TLBs state is unknown...
> 
> IMO, although that might improve the status quo, there are still
> heuristics, in addition to noticeable complexity to transition the
> stream tables. I wonder if FW can deal with AER in that case before
> booting the kdump kernel.

I guess we're reading the base address from the HW register itself so
that should be fine? CDs are in-memory so that's why they could be
corrupted?

About the TLB state, I'm not sure what might pollute it, since this is a
kexec, I don't expect any non-kernel entity to gain program control
before the kdump kernel.. Hence, IMO, we can't configure FW to deal with
AER here..

Thanks,
Praan