Re: [PATCH v11 05/11] iommu/arm-smmu-v3: Disable the EVTQ and the PRIQ in a kdump kernel
From: Mostafa Saleh
Date: Tue Oct 20 2026 - 07:26:20 EST
On Mon, Oct 05, 2026 at 12:30:48PM -0700, Nicolin Chen wrote:
> A kdump kernel cannot use either queue. The crashed kernel's CDs and page
> tables might be corrupted, so events would spam the EVTQ, and there is no
> way to serve the page requests that would arrive at the PRIQ.
>
> The reset routine still enables both of the queues and then masks the two
> enable bits back out, having already programmed the queue bases and taken
> the interrupts of both.
>
> Clear ARM_SMMU_FEAT_EVTQ and ARM_SMMU_FEAT_PRI in the probe instead, so as
> to entirely skip the queue initialization and handling in a kdump kernel.
>
> Suggested-by: Will Deacon <will@xxxxxxxxxx>
> Link: https://lore.kernel.org/all/amiBagGKn-Aym1DK@willie-the-truck/
> Acked-by: Kiryl Shutsemau (Meta) <kas@xxxxxxxxxx>
> Reviewed-by: Jason Gunthorpe <jgg@xxxxxxxxxx>
> Tested-by: Breno Leitao <leitao@xxxxxxxxxx>
> Tested-by: Cristian Prundeanu <cpru@xxxxxxxxxx>
> Assisted-by: LLM
> Signed-off-by: Nicolin Chen <nicolinc@xxxxxxxxxx>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 756825e004774..42cd30c79211e 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -5247,9 +5247,6 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu)
> return ret;
> }
>
> - if (is_kdump_kernel())
> - enables &= ~(CR0_EVTQEN | CR0_PRIQEN);
> -
> /* Enable the SMMU interface */
> enables |= CR0_SMMUEN;
> ret = arm_smmu_write_reg_sync(smmu, enables, ARM_SMMU_CR0,
> @@ -5576,6 +5573,15 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
> if (arm_smmu_sva_supported(smmu))
> smmu->features |= ARM_SMMU_FEAT_SVA;
>
> + /*
> + * A kdump kernel wants neither queue: the crashed kernel's CDs and page
> + * tables might be corrupted, spamming events, and page requests cannot
> + * be served. A disabled queue discards new records without raising any
> + * global error.
> + */
I find this a bit confusing. If the CD or page table of the crashed kernel are
corrupted how is it safe to adopt them later in this series?
Thanks,
Mostafa
> + if (is_kdump_kernel())
> + smmu->features &= ~(ARM_SMMU_FEAT_EVTQ | ARM_SMMU_FEAT_PRI);
> +
> dev_info(smmu->dev, "oas %lu-bit (features 0x%08x)\n",
> smmu->oas, smmu->features);
> return 0;
> --
> 2.43.0
>