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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] If a multi-stream master device (`num_streams > 1`) has `stall_enabled` set, any stalled transaction on a stream other than index 0 will be replied to with the wrong Stream ID, permanently locking up the stalled stream and the interconnect.
--

commit e5bd1a5ac6f06fe386135f8eef6843d3096e660e
Author: Malak Marrid <mmarrid@nvidia.com>

iommu/arm-smmu-v3: Submit CMDQ_OP_PRI_RESP for IOPF event

This commit updates arm_smmu_page_response() to issue a CMDQ_OP_PRI_RESP
for IOMMU_FAULT_PAGE_REQ events when PRI is enabled. It maps IOMMU page
response codes to PRI response codes and extends arm_smmu_enable_iopf()
to allow PRI-enabled masters.

> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 352c916b2a572..64540cfb73244 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c

[ ... ]

> @@ -1028,32 +1028,69 @@ static int arm_smmu_drain_queue(struct arm_smmu_device *smmu,
>  static void arm_smmu_page_response(struct device *dev, struct iopf_fault *evt,
>  				   struct iommu_page_response *resp)
>  {
>  	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> +	struct arm_smmu_cmd cmd;
> +	int sid;
>  
> +	if (WARN_ON_ONCE(evt->fault.type != IOMMU_FAULT_PAGE_REQ))
>  		return;
>  
> +	/* IOPF is gated to num_streams == 1 in arm_smmu_enable_iopf() */
> +	sid = master->streams[0].id;

[Severity: High]
This is a pre-existing issue, but does this hardcoded stream ID assignment
handle multi-stream devices correctly?

If a multi-stream master device (num_streams > 1) has the dma-can-stall
property enabled, arm_smmu_probe_device() unconditionally sets
master->stall_enabled = true.

If a translation fault occurs on any stream ID other than index 0, the
hardware generates a stall event. Because arm_smmu_enable_iopf() rejects
num_streams != 1, the IOMMU fault framework fails to find a registered
IOPF handler and falls back to an error response via
arm_smmu_page_response().

Since this function hardcodes sid = master->streams[0].id for the
CMDQ_OP_RESUME command, the actual faulting stream never receives a resume
command.

Can this result in a hardware interconnect lockup because the SMMU
permanently stalls the transaction on the faulting stream?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1788222485.git.nicolinc@nvidia.com?part=6