Re: [PATCH v3 08/13] iommu/arm-smmu-v3: Disable PRI when no IRQ handler is registered

[Nicolin Chen]

On Wed, Sep 09, 2026 at 10:59:54AM -0700, Jonathan Cameron wrote:
> On Fri, 4 Sep 2026 11:15:25 -0300
> Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:
> 
> > On Thu, Sep 03, 2026 at 12:18:33PM -0700, Jonathan Cameron wrote:
> > > > arm_smmu_setup_irqs() has three failure paths that leave the priq without
> > > > a handler: a missing priq IRQ line, devm_request_threaded_irq() failure on
> > > > the priq IRQ, and devm_request_threaded_irq() failure on the combined IRQ.
> > > > Each path warned but kept ARM_SMMU_FEAT_PRI set in smmu->features.
> > > > 
> > > > With FEAT_PRI still set, arm_smmu_setup_irqs() enables IRQ_CTRL_PRIQ_IRQEN
> > > > against a handler that does not exist, and a later change would then have
> > > > arm_smmu_probe_device() call pci_enable_pri() on PCIe endpoints, allowing
> > > > them to issue PRI Page Requests that pile up in the priq with no drainer.
> > > > Separately, arm_smmu_device_reset() has already enabled CR0_PRIQEN before
> > > > it invoked arm_smmu_setup_irqs(), so the hardware queue would stay enabled
> > > > regardless of what setup_irqs decides.
> > > > 
> > > > Clear ARM_SMMU_FEAT_PRI in all three failure paths, so that subsequent code
> > > > treats PRI as unavailable. And disable CR0_PRIQEN after the setup function
> > > > returns.
> > > > 
> > > > A kdump kernel cannot service page requests: strip FEAT_PRI when detecting
> > > > features, so downstream PRI setup is skipped.  
> > > 
> > > Dumb question - why can't a kdump kernel service page requests?
> > > I'm nowhere near familiar enough with that stuff and I suspect I'm not
> > > the only one who might be in that state and reading this series.
> > > Configuration choice, or a fundamental thing?  
> > 
> > The initial issue is the streams are left in whatever state the crash
> > kernel had them in, so it can be generating a bunch of PRIs with no
> > place to put them.
> > 
> > Though eventually we may find a device where dropping them is not good
> > and they need to be NAK'd promptly..
> > 
> > But I think the real motivation here is to save memory in the kdump
> > kernel..
> 
> Got it, so design decision rather than fundamental.  Maybe tweak that text
> to say 
> "A kdump kernel doesn't service page request" ?

Sure. Fixed.

Thanks
Nicolin