Re: [PATCH 2/2] iommu/arm-smmu-v3: Override for Inst/Data attribute

Hi folks,

On Mon, 10 Aug 2026 at 15:43, Robin Murphy <[email protected]> wrote:
>
> On 10/08/2026 3:15 pm, Jason Gunthorpe wrote:
> > On Fri, Aug 07, 2026 at 03:37:37PM +0100, Peter Griffin wrote:
> >
> >>>> @@ -1222,7 +1224,8 @@ void arm_smmu_get_ste_used(const __le64 *ent, __le64 *used_bits)
> >>>>        if (cfg & BIT(1)) {
> >>>>                used_bits[1] |=
> >>>>                        cpu_to_le64(STRTAB_STE_1_S2FWB | STRTAB_STE_1_EATS |
> >>>> -                                 STRTAB_STE_1_SHCFG | STRTAB_STE_1_MEV);
> >>>> +                                 STRTAB_STE_1_SHCFG | STRTAB_STE_1_MEV |
> >>>> +                                 STRTAB_STE_1_INSTCFG);
> >>>>                used_bits[2] |=
> >>>>                        cpu_to_le64(STRTAB_STE_2_S2VMID | STRTAB_STE_2_VTCR |
> >>>>                                    STRTAB_STE_2_S2AA64 | STRTAB_STE_2_S2ENDI |
> >>>
> >>> This adds for "stage-1" and "stage-2", while missing "bypass"?
> >>
> >> I need to follow up again on this point, but I don't believe currently
> >> we require the override for Laguna when it's in bypass.
> >
> > Oh? Why not?
> >
> > Is the issue the IOPTEs are set to no-exec or something like that?
>
> In general, there isn't expected to be anything in the memory system
> downstream of the SMMU that makes use of the Privileged or
> Instruction/Data attributes, so I would assume that is the case on this
> SoC. FWIW, hardware folks would be quite keen on relaxing the
> architecture to say that an SMMU isn't even required to propagate those
> attributes at all.

As Robin mentioned above, there is nothing downstream of the SMMU that
cares about the AxPROT[2] Instruction/Data attribute. So it could be
added I guess for consistency reasons, but it seemed better not to add
any code we don't strictly require. Maybe a comment should be added to
_bypass to explain the inconsistency?

Thanks,

Peter