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

[Robin Murphy <robin.murphy@arm.com>]

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@arm.com> 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.