Re: [PATCH RFC 2/2] remoteproc: qcom_q6v5_pas: map SOCCP carveout privileged-only

[Shawn Guo <shengchao.guo@oss.qualcomm.com>]

On Fri, Nov 13, 2026 at 05:54:13PM +0530, Anurag Pateriya wrote:
> From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
> 
> SOCCP is a RISC-V core whose instruction fetches go through the
> SMMU in privilege mode
> 
> The memory region is mapped with IOMMU_READ | IOMMU_WRITE, which results
> in permission fault when SOCCP fetches instruction, append IOMMU_PRIV to
> mapping to allow it to fetch instructions.

This says what fails and what makes it go away, but not why. A reader
can't tell from this why an RW mapping is fine for a data access but
faults on an instruction fetch, or why IOMMU_PRIV fixes it.

As I understand it, the chain is:

- Without IOMMU_PRIV, io-pgtable-arm sets AP[1] in the stage-1 PTE,
  so the carveout ends up AP[2:1] = 0b01, i.e. writable at the
  unprivileged level.

- In the VMSAv8-64 stage-1 permission model, memory writable at the
  unprivileged level is implicitly privileged-execute-never,
  regardless of PXN.

- SoCCP fetches arrive as privileged instruction transactions, so
  the first fetch takes a stage-1 permission fault (FSR.PF,
  FSYNR0.IND=1).

- IOMMU_PRIV clears AP[1] (AP[2:1] = 0b00, privileged RW only),
  which removes the implicit PXN.

Something along these lines:

  On Nord, when Linux runs at EL2 it owns the SoCCP stream and the
  remoteproc core maps the firmware carveout through a stage-1 SMMU
  context bank. qcom_pas_map_carveout() uses IOMMU_READ | IOMMU_WRITE
  without IOMMU_PRIV, so io-pgtable-arm builds stage-1 PTEs with
  AP[2:1] = 0b01: read/write at both privileged and unprivileged
  level.

  SoCCP is a RISC-V core whose instruction fetches reach the SMMU as
  privileged transactions. In the VMSAv8-64 stage-1 permission model,
  memory that is writable at the unprivileged level is implicitly
  privileged-execute-never, regardless of the PXN bit in the PTE. The
  first SoCCP instruction fetch after PAS authentication therefore
  takes a stage-1 permission fault (FSR.PF, FSYNR0.IND=1).

  Map the SoCCP carveout with IOMMU_PRIV, so the stage-1 PTEs are
  privileged read/write only (AP[2:1] = 0b00). This removes the
  implicit privileged-execute-never and lets SoCCP fetch from the
  carveout.

  Other PIL subsystems (e.g. Hexagon Q6) are not affected as their
  instruction fetches do not go through the SMMU in privileged mode.

Another nit: please use SoCCP (instead of SOCCP) everywhere, e.g. patch
subject, for sake of consistency.

Shawn