Re: [PATCH 0/2] Add arm-smmu-v3 support for instcfg data override feature

Hi Will,

On Wed, 12 Aug 2026 at 11:41, Will Deacon <[email protected]> wrote:
>
> On Mon, Aug 10, 2026 at 06:16:56PM +0100, Robin Murphy wrote:
> > 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 <[email protected]> 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.
>
> Ok, I did a bit of digging internally and it looks like the situation
> isn't quite what has been described here:

Thanks Will for taking the time to dig into this.

>
> - The issue is that AxPROT is wired so that all transactions appear as
>   instructions. This is an SMMU integration problem and happens
>   irrespective of the client device.
>
> - Transactions are _not_ forced to be privileged. That appears to be a
>   mistake earlier in the thread.

Yes, sorry about that. That was my mistake. The information I found
about this issue unfortunately contained that misinformation. Daniel
Mentz corrected this in a follow up email, though. In the next version
I'll use your and Daniel's more verbose description of the issue.

>
> - The reason privilege is interesting is because of Robin's point that
>   the architecture forces privileged XN for unpriviliged W.
>
> So, based on that, I think the instcfg override makes sense.

Ok, great thanks for confirming.

Peter