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

From: Jonathan Cameron

Date: Wed Sep 09 2026 - 15:17:49 EST


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" ?
>
> Jason
>