Re: [PATCH v3 06/13] iommu/arm-smmu-v3: Submit CMDQ_OP_PRI_RESP for IOPF event

[Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>]

On Fri, 4 Sep 2026 18:15:37 -0700
Nicolin Chen <nicolinc@nvidia.com> wrote:

> On Thu, Sep 03, 2026 at 12:18:33PM -0700, Jonathan Cameron wrote:
> > > To handle IOMMU_FAULT_PAGE_REQ from the PRI queue, arm_smmu_page_response()
> > > must issue a CMDQ_OP_PRI_RESP back to the SMMU.
> > > 
> > > A stall event in the EVTQ and a PRI request in the PRIQ both surface to the
> > > IOPF infrastructure with fault.type == IOMMU_FAULT_PAGE_REQ. SMMUv3 forbids
> > > the Stall model on PCIe streams (PCIe must use Terminate), and PRI is only  
> > 
> > There are those systems that annoy some because they smell like PCIe
> > (present PCIe software interfaces) but aren't and use stall mode. However, it
> > is nonsense to use PRI with stall mode. So, instead I'd just argue that for
> > stall the fault handling is done synchronously from a device point of
> > view so a PRI request makes no sense rather htan associating this with
> > PCIe as such.  
> 
> I changed the paragraph to:
> 
> A stall event in the EVTQ and a PRI request in the PRIQ both surface to the
> IOPF infrastructure with fault.type == IOMMU_FAULT_PAGE_REQ. Yet, both two
> models are alternatives: a stalling master resolves a fault synchronously,
> holding the transaction until a CMDQ_OP_RESUME, so it has no reason to also
> issue a page request. A later change refuses PRI on a stall_enabled master,
> so the two will never co-occur. arm_smmu_page_response() can therefore key
> on the master state: CMDQ_OP_RESUME for stall_enabled, CMDQ_OP_PRI_RESP for
> pri_enabled, mapping IOMMU_PAGE_RESP_* to the PRI response codes.
> 
Nice.