mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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
> 

  parent reply	other threads:[~2026-10-21 13:45 UTC|newest]

Thread overview: 41+ 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-22  8:41       ` John Garry
2026-10-22 12:22         ` Jason Gunthorpe
2026-10-22 12:49           ` John Garry
2026-10-22 15:16         ` 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-22 11:02   ` John Garry
2026-10-22 15:18     ` 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 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®