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

[Jason Gunthorpe <jgg@nvidia.com>]

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..

Jason