Re: [RFC v5 12/28] hw/arm/smmuv3: Tag IOTLB cache keys with SEC_SID

[Mostafa Saleh <smostafa@google.com>]

On Mon, Sep 07, 2026 at 06:03:25PM +0200, Eric Auger wrote:
> 
> 
> On 9/7/26 5:35 PM, Mostafa Saleh wrote:
> > On Mon, Sep 07, 2026 at 04:49:58PM +0200, Eric Auger wrote:
> >>
> >> On 9/1/26 4:11 PM, Mostafa Saleh wrote:
> >>> On Fri, Aug 14, 2026 at 12:25:09AM +0800, Tao Tang wrote:
> >>>> To prevent aliasing between translations controlled through the Secure and
> >>>> Non-secure programming interfaces, the IOTLB lookup key must incorporate
> >>>> SEC_SID.
> >>>>
> >>>> This commit:
> >>>> - expands SMMUIOTLBKey with SEC_SID field for cache key differentiation
> >>> I still feel that it's better to have a separate IOTLB for the secure
> >>> world, as it should never mix with the non-secure one; as I commented
> >>> on the last version:
> >>> https://lore.kernel.org/qemu-devel/aaGuGuevX8HFqx0x@google.com/
> >>>
> >>> Then all the functions can be re-used and it is just a matter
> >>> of passing the right instance.
> >>>
> >>> No strong opinion though, this approach should work also, so it is up
> >>> to Eric.
> >> I don't have a strong opinion either. I am just curious about what the
> >> implementation will become once we add further support for StreamWorld.
> >> Will we be able to keep separate IOTLBs or will it make more sense to
> >> have a unified IOTLB?
> > Is that about the possiblity of mixing TLB entries accross different
> > StreamWorlds, as I don't see immediately if that is possible.
> >
> > Or is it about growing number of IOTLB instances as we support
> > StreamWorlds? I am not really sure about that as there are many
> > possibilities (NS-EL1, NS-EL2, NS-EL2-E2H, Same for S, and realm)
> >
> > I'd imagine we have 3 instances NS, S and Realm but each one would
> > need a STRW anyway, so maybe having a big one is not that bad.
> Yes that was the question. Do we plan to have a multiplication of IOTLBs
> for each streamworld value in which case it may become messy?
> 
> Anyway we can rework later. So I would say pick up your prefered solution.

Let's keep it as it is now then (shared IOTLB). After more thinking I
believe that would scale better.

Thanks,
Mostafa

> 
> Eric
>