From: Mostafa Saleh <smostafa@google.com>
To: Nicolin Chen <nicolinc@nvidia.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: Wed, 21 Oct 2026 13:45:03 +0000 [thread overview]
Message-ID: <atjB34tvJySp9abz@google.com> (raw)
In-Reply-To: <atemgT/67JPpdk57@nvidia.com>
On Tue, Oct 20, 2026 at 10:36:01AM -0700, Nicolin Chen wrote:
> 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;
>
That makes more sense with the comment about for structural validation,
although.
> > > + 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.
I see, I have no strong opinion, but I think we can just ignore sashiko
here, and this can be a limitation as long as it fails gracefully, it
makes the patch slightly easier to reason about.
>
> > > + } 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?
I see, I missed it is also used in devm_add_action_or_reset()
Thanks,
Mostafa
>
> Thanks
> Nicolin
>
next prev parent reply other threads:[~2026-10-21 13:45 UTC|newest]
Thread overview: 35+ 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
2026-10-20 17:47 ` Nicolin Chen
2026-10-21 13:45 ` Mostafa Saleh [this message]
2026-10-21 16:37 ` John Garry
2026-10-21 17:50 ` Nicolin Chen
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-21 16:53 ` John Garry
2026-10-21 17:52 ` Nicolin Chen
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=atjB34tvJySp9abz@google.com \
--to=smostafa@google.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=nicolinc@nvidia.com \
--cc=praan@google.com \
--cc=robin.murphy@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.