[PATCH v4 10/15] iommu/arm-smmu-v3: Support PRI Page Request in arm_smmu_handle_ppr()

[Nicolin Chen]

On Thu, Sep 10, 2026 at 05:14:05PM -0700, Jonathan Cameron wrote:
> > @@ -2380,9 +2381,47 @@ static void arm_smmu_handle_ppr(struct arm_smmu_device *smmu, u64 *evt)
> >  	last = FIELD_GET(PRIQ_0_PRG_LAST, evt[0]);
> >  	grpid = FIELD_GET(PRIQ_1_PRG_IDX, evt[1]);
> >  
> > -	dev_info(smmu->dev, "unexpected PRI request received:\n");
> > -	dev_info(smmu->dev,
> > -		 "\tsid 0x%08x.0x%05x: [%u%s] %sprivileged %s%s%s access at iova 0x%016llx\n",
> > +	/*
> > +	 * A PASID Stop Marker (LRW = 0b100) does not expect a response and
> > +	 * must be discarded before fault reporting: see the documentation
> > +	 * at iommu_report_device_fault().
> > +	 */
> > +	if (last && !(evt[0] & (PRIQ_0_PERM_READ | PRIQ_0_PERM_WRITE)))
> 
> There is a bit of spec language about case where there is no PASID
> LWR=0xb100 not being a stop marker, SSV == 0 and should be treated as
> a PRI request. I'm not sure what that means in practice but maybe
> a comment on why that case doesn't matter. Feels like breadcrumbs we
> might need in future.

That's a sharp one! I didn't find any the practical action was
suggested either.

I wonder if we should let it fall through instead of a return:

	/*
	 * A PASID Stop Marker (LRW = 0b100) does not expect a response and
	 * must be discarded before fault reporting: see the documentation
	 * at iommu_report_device_fault().
	 *
	 * Gate it on SSV, as without a PASID that same encoding is a PRI Page
	 * Request and it does expect a response. So let it fall through and be
	 * answered with a PRI_RESP_FAIL, since iommu_sva_handle_mm() rejects a
	 * PASID-less fault, or by the PRI_RESP_DENY issued below.
	 */
	if (last && ssv && !(evt[0] & (PRIQ_0_PERM_READ | PRIQ_0_PERM_WRITE)))
		return;

Thanks
Nicolin