From: Nicolin Chen <nicolinc@nvidia.com>
To: Mostafa Saleh <smostafa@google.com>
Cc: <will@kernel.org>, <robin.murphy@arm.com>, <joro@8bytes.org>,
<jgg@nvidia.com>, <praan@google.com>, <kevin.tian@intel.com>,
<linux-arm-kernel@lists.infradead.org>, <iommu@lists.linux.dev>,
<linux-kernel@vger.kernel.org>, <jamien@nvidia.com>,
<kas@kernel.org>, Cristian Prundeanu <cpru@amazon.com>,
Breno Leitao <leitao@kernel.org>
Subject: Re: [PATCH v11 06/11] iommu/arm-smmu-v3: Add ARM_SMMU_OPT_KDUMP_ADOPT for kdump kernel
Date: Tue, 20 Oct 2026 10:36:01 -0700 [thread overview]
Message-ID: <atemgT/67JPpdk57@nvidia.com> (raw)
In-Reply-To: <atdSrRwrphdI9ZQA@google.com>
On Tue, Oct 20, 2026 at 11:38:21AM +0000, Mostafa Saleh wrote:
> On Mon, Oct 05, 2026 at 12:30:49PM -0700, Nicolin Chen wrote:
> > + /*
> > + * According to spec (6.3.24), HW aligns the base down to the table size
> > + * and ignores the low bits, so an unaligned base would make this kernel
> > + * read a different table.
> > + */
> > + if (!IS_ALIGNED(base, size)) {
> > + dev_err(smmu->dev, "unaligned stream table base %pa\n", &base);
>
> I understand these are best effort, but what happens if the address
> corrupted and happens to be aligned?
This is a basic sanity so HW wouldn't immediately fail. A corrupted
address would be trickier to test out; also we don't have a perfect
way to do that. Earlier versions had some address range check. I've
dropped it, following Jason's comments.
This is also in the kdocs of the whole smmu kdump functions:
* - Only a coherent SMMU (ARM_SMMU_FEAT_COHERENCY) is supported, as the stream
* table adoption is done by memremap with MEMREMAP_WB, which is verified on
* the real hardware. Callers of these functions are responsible for gating
* ARM_SMMU_FEAT_COHERENCY once during the probe.
*/
> > +int arm_smmu_kdump_adopt_deferred_l2_strtab(struct arm_smmu_device *smmu,
> > + u32 sid, phys_addr_t base, u32 span,
> > + struct arm_smmu_strtab_l2 **l2table)
> > +{
> > + struct arm_smmu_strtab_l2 *table;
> > + size_t size;
> > +
> > + /*
> > + * Retest the span in case the L1 descriptor has been overwritten since
> > + * the adopt. Reject this master's insert; panic or SMMU-disable would
> > + * either lose the vmcore or cascade aborts. Do not try to fix it, as it
> > + * would break all other SIDs in the same bus (PCI case). The corruption
> > + * blast radius is already bounded to that bus range.
> > + */
> > + if (span != STRTAB_SPLIT + 1) {
> > + dev_err(smmu->dev,
> > + "L1[%u] span %u changed since adopt (was %u)\n",
> > + arm_smmu_strtab_l1_idx(sid), span, STRTAB_SPLIT + 1);
> > + return -EINVAL;
> > + }
> > +
> > + size = (1UL << (span - 1)) * sizeof(struct arm_smmu_ste);
> > +
> > + /* Same live-corruption check as the span; reject an overwritten base */
> > + if (!base || !IS_ALIGNED(base, size)) {
> > + dev_err(smmu->dev, "L1[%u] bad l2 table base %pa\n",
> > + arm_smmu_strtab_l1_idx(sid), &base);
> > + return -EINVAL;
> > + }
> > +
>
> Those are a bit similar to arm_smmu_kexec_parse_strtab_2lvl() is it
> possible to have some helpers instead?
Sure. I can do that.
> > +int arm_smmu_kdump_adopt_strtab(struct arm_smmu_device *smmu)
> > +{
> > + u32 cfg_reg = readl_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE_CFG);
> > + u64 base_reg = readq_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE);
> > + bool was_2lvl = smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB;
> > + phys_addr_t base = base_reg & STRTAB_BASE_ADDR_MASK;
> > + u32 fmt = FIELD_GET(STRTAB_BASE_CFG_FMT, cfg_reg);
> > + int ret;
> > +
> > + dev_dbg(smmu->dev, "adopting crashed kernel's stream table\n");
> > +
> > + if (fmt == STRTAB_BASE_CFG_FMT_2LVL) {
> > + /*
> > + * Both kernels run on the same hardware, so it's impossible for
> > + * kdump kernel to see the support for linear stream table only.
> > + */
>
> STRTAB_SPLIT which influences ARM_SMMU_FEAT_2_LVL_STRTAB is a SW choice, so it is
I missed that.
> possible to get such mismatch if STRTAB_SPLIT of the newer kernel is larger than the
> older kernel.
> However, I agree that in that case it's better to refuse the adoption.
>
> > + if (WARN_ON(!(smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB)))
> > + ret = -EINVAL;
I can replace the FEAT guard here with
if (WARN_ON(FIELD_GET(IDR0_ST_LVL, idr0) != IDR0_ST_LVL_2LVL))
ret = -EINVAL;
> > + else
> > + ret = arm_smmu_kdump_adopt_strtab_2lvl(smmu, cfg_reg,
> > + base);
> > + } else if (fmt == STRTAB_BASE_CFG_FMT_LINEAR) {
> > + /*
> > + * The kdump kernel need not match the crashed kernel. An older
> > + * crashed kernel that predates two-level stream table support
> > + * may have used a linear table on 2-level-capable hardware, so
> > + * enforce the same format here to match the adopted table.
> > + */
> > + ret = arm_smmu_kdump_adopt_strtab_linear(smmu, cfg_reg, base);
> > + if (!ret)
> > + smmu->features &= ~ARM_SMMU_FEAT_2_LVL_STRTAB;
>
> For simplicity, it is better to enforce the same table formats between
> kernels as the rest of the file, for example,
> arm_smmu_kexec_parse_strtab_2lvl() refuses different STRTAB_SPLIT.
> Some checks can be removed and the was_2lvl error path. It's
> very unlikely to hit such case anyway.
Sashiko pointed out a corner case that a modified kernel kdumps
into a vanilla kernel. It is not really a big effort to support
it. So, I would rather keep this.
> > + } else {
> > + dev_err(smmu->dev, "invalid STRTAB format %u\n", fmt);
> > + ret = -EINVAL;
> > + }
> > +
> > + if (ret) {
> > + arm_smmu_kdump_adopt_cleanup(smmu);
>
> Probably easier to inline the error handling after each call and remove this?
I don't quite follow this. The clean function is used by three
sites. How can we remove it?
Thanks
Nicolin
next prev parent reply other threads:[~2026-10-20 17:36 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 19:30 [PATCH v11 00/11] iommu/arm-smmu-v3: Adopt the crashed kernel's stream table for kdump Nicolin Chen
2026-10-05 19:30 ` [PATCH v11 01/11] iommu/arm-smmu-v3: Init the vmid_map ida before the stream table setup Nicolin Chen
2026-10-20 11:13 ` Mostafa Saleh
2026-10-05 19:30 ` [PATCH v11 02/11] iommu/arm-smmu-v3: Make the ASID space per SMMU instance Nicolin Chen
2026-10-20 11:14 ` Mostafa Saleh
2026-10-05 19:30 ` [PATCH v11 03/11] iommu/arm-smmu-v3: Swap EVTQ_MSI_INDEX and GERROR_MSI_INDEX Nicolin Chen
2026-10-13 14:49 ` Jason Gunthorpe
2026-10-13 17:41 ` Nicolin Chen
2026-10-20 14:26 ` Jason Gunthorpe
2026-10-05 19:30 ` [PATCH v11 04/11] iommu/arm-smmu-v3: Add ARM_SMMU_FEAT_EVTQ for the event queue Nicolin Chen
2026-10-20 11:16 ` Mostafa Saleh
2026-10-20 16:49 ` Nicolin Chen
2026-10-05 19:30 ` [PATCH v11 05/11] iommu/arm-smmu-v3: Disable the EVTQ and the PRIQ in a kdump kernel Nicolin Chen
2026-10-20 11:22 ` Mostafa Saleh
2026-10-20 16:59 ` Nicolin Chen
2026-10-05 19:30 ` [PATCH v11 06/11] iommu/arm-smmu-v3: Add ARM_SMMU_OPT_KDUMP_ADOPT for " Nicolin Chen
2026-10-20 11:38 ` Mostafa Saleh
2026-10-20 14:25 ` Jason Gunthorpe
2026-10-20 17:36 ` Nicolin Chen [this message]
2026-10-05 19:30 ` [PATCH v11 07/11] iommu/arm-smmu-v3-kexec: Reserve crashed kernel's ASIDs and VMIDs Nicolin Chen
2026-10-05 19:30 ` [PATCH v11 08/11] iommu/arm-smmu-v3-kexec: Implement is_attach_deferred() Nicolin Chen
2026-10-05 19:30 ` [PATCH v11 09/11] iommu/arm-smmu-v3: Retain CR0_SMMUEN during kdump device reset Nicolin Chen
2026-10-13 14:49 ` Jason Gunthorpe
2026-10-05 19:30 ` [PATCH v11 10/11] iommu/arm-smmu-v3: Skip RMR bypass for kdump adoption Nicolin Chen
2026-10-05 19:30 ` [PATCH v11 11/11] iommu/arm-smmu-v3: Detect ARM_SMMU_OPT_KDUMP_ADOPT in probe() Nicolin Chen
2026-10-05 20:48 ` [PATCH v11 00/11] iommu/arm-smmu-v3: Adopt the crashed kernel's stream table for kdump Nicolin Chen
2026-10-17 8:19 ` Shuai Xue
2026-10-17 11:40 ` Jason Gunthorpe
2026-10-17 18:52 ` Nicolin Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atemgT/67JPpdk57@nvidia.com \
--to=nicolinc@nvidia.com \
--cc=cpru@amazon.com \
--cc=iommu@lists.linux.dev \
--cc=jamien@nvidia.com \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kas@kernel.org \
--cc=kevin.tian@intel.com \
--cc=leitao@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=praan@google.com \
--cc=robin.murphy@arm.com \
--cc=smostafa@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®