On 9/8/2026 4:19 PM, Mostafa Saleh wrote:
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/[email protected]/
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.
Hi Eric, Mostafa,
Thanks for the feedback. I'll keep the shared IOTLB for this series. We
can revisit the table layout and eviction policy later if needed.
Thanks,
Tao
