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

[Jonathan Cameron]

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

Otherwise, seems fine to me.

Reviewed-by: Jonathan Cameron <jonathan.cameron@xxxxxxxxxxxxxxxx>

-- 
Jonathan Cameron <jonathan.cameron@xxxxxxxxxxxxxxxx>