Re: [PATCH 0/2] Add arm-smmu-v3 support for instcfg data override feature
From: Robin Murphy
Date: Mon Aug 10 2026 - 13:17:17 EST
On 10/08/2026 12:00 pm, Will Deacon wrote:
On Fri, Aug 07, 2026 at 04:25:11PM +0100, Peter Griffin wrote:
On Mon, 27 Jul 2026 at 11:53, Robin Murphy <robin.murphy@xxxxxxx> wrote:
On 26/07/2026 2:16 pm, Will Deacon wrote:
On Fri, Jul 24, 2026 at 01:39:41PM +0100, Peter Griffin wrote:
These two patches add support for a new "arm,instdata-override" DT property
that enables the override of the instruction/data attribute of incoming
traffic to Data by setting the INSTCFG override bits.
It is intended to be specified when the smmu can't guarantee that these
attributes are provided correctly from the client device.
This is going to need an in-tree user and a much more detailed
description of what is being worked around before we consider this for
inclusion.
Regarding an in-tree user, I haven't sent the Device Tree (DT) patch
yet for Laguna SoC which adds the smmu nodes and this property because
1) I want to land the initial SoC/board DT first
2) I want agreement on the DT property name. Currently I used
"arm,instdata-override" which is what downstream used. However, since
this is intended to work around silicon errata something like
"google,lga-instcfg-data-override" might be more appropriate?
For Laguna SoC the first in-tree user of this is the amb_smmu smmu
instance which is used by the Synopsis dwc3 IP. The Laguna dwc3 glue
driver is already upstream at drivers/usb/dwc3/dwc3-google.c
In particular, if a particular client is emitting data reads as
instructions, then a better work around would be to avoid mapping its
domains using IOMMU_NOEXEC. But I can't tell what's going on from the
limited description provided here.
Unless it's also emitting the privileged bit and thus falling foul of
the implicit Unpriv-W -> Priv-XN rule, but then we also have the means
to deal with devices which actually do that themselves (hello pl330...),
so that would seemingly only leave the case of some innocent piece of
AMBA-interfaced IP which doesn't expect to need special attributes, but
the system integrator has gone out of their way to tie the AxPROT bits
to some wacky value, which I would put in "erratum workaround" territory.
You're correct Robin. It is an erratum workaround for the Laguna SoC
due to some custom usage of the AxPROT bits which differs from the
standard ARM SMMU handling for Privileged/Unprivileged and
Instruction/Data transaction attributes. The effect is all
transactions appear to the SMMU as "Privileged Instruction" accesses.
Ah, so this sounds like what Robin was worried about.
The software workaround in this series enables the SMMU's INSTCFG
override feature to ignore the incoming value and treat all SMMU
transactions as "Data".
One small clarification: in the cover letter I incorrectly said this
was set only for some SMMU IP instances, but that is incorrect. It is
actually set on *all* arm-smmu-v3 IP instances in the Laguna SoC.
Does the above provide the additional detail you need Will?
So it sounds like using the instcfg override on this hardware still breaks
IOMMU_PRIV and IOMMU_NOEXEC:
1. If you don't pass IOMMU_PRIV, you still get privileged transactions
However this is inherently true of VMSA stage 1 anyway - I admit I had to double-check, but we don't have any user-only permissions (other than perhaps execute as implied by explicit or implicit PXN). IOMMU_PRIV can only _remove_ unprivileged access.
2. If you don't pass IOMMU_NOEXEC, you do not get execute permission
Is that correct?
Perhaps it would be better to override PRIVCFG to force unprivileged,
then reject IOMMU_PRIV and ignore IOMMU_NOEXEC?
From what Daniel said, it sounds like the privileged attribute is still the doing of the device itself rather than the integration issue in this case, so while nobbling PRIVCFG might also achieve the end result of making IOMMU_READ | IOMMU_WRITE pages mostly not fault on reads, it seems less appropriate as a workaround. Particularly since IOMMU_PRIV is exposed via a general DMA API attribute, while IOMMU_NOEXEC is only accessible to dedicated IOMMU API/io-pgtable users.
Thanks,
Robin.