Re: [PATCH v9 01/12] iommu/arm-smmu-v3: Do not enable EVTQ/PRIQ interrupts in kdump kernel

On Fri, Aug 21, 2026 at 08:15:25PM -0300, Jason Gunthorpe wrote:
> >  static irqreturn_t arm_smmu_combined_irq_handler(int irq, void *dev)
> >  {
> > -	arm_smmu_gerror_handler(irq, dev);
> > +	irqreturn_t ret = arm_smmu_gerror_handler(irq, dev);
> > +
> > +	/* In kdump, EVTQ/PRIQ are disabled and there is no thread to wake */
> > +	if (is_kdump_kernel())
> > +		return ret;
> >  	return IRQ_WAKE_THREAD;
> 
> To Robin's earlier point, how about some ARM_SMMU_FEAT_EVTQ ? We already have
> ARM_SMMU_FEAT_PRI. Unset these by kdump instead of sprinkling kdump things
> everywhere?
> 
> I'm not especially kean on these kdump annotations as a long term
> maintainability, but having a FEAT to protect a well defined area of
> functionality seems more understandable long term.

I've added a new patch adding ARM_SMMU_FEAT_EVTQ.

> > +> @@ -4682,19 +4691,30 @@ static int arm_smmu_setup_irqs(struct arm_smmu_device *smmu)
> >  		/*
> >  		 * Cavium ThunderX2 implementation doesn't support unique irq
> >  		 * lines. Use a single irq line for all the SMMUv3 interrupts.
> > +		 *
> > +		 * In kdump, EVTQ/PRIQ are disabled, so no threaded handling.
> >  		 */
> 
> Why? I mean I get we might not need a threaded IRQ handler without PRI, but is
> there a reason kdump would not want to create one anyhow?

In kdump case, only GERROR is left. So, I thought it could match
the non-combined case.

But it's probably okay to remain to be threaded. Also, since we
gate interrupts with the FEAT_PRIQ and FEAT_EVTQ in the combined
handler, it makes things here cleaner.

Thanks
Nicolin