Hi Mostafa,
On 2026/2/27 PM10:45, Mostafa Saleh wrote:
On Sat, Feb 21, 2026 at 06:16:40PM +0800, Tao Tang wrote:
This is a non-functional preparation step that adds storage for
resolved security state in SMMUTLBEntry.
I am not sure about this, when I added stage-2 I re-used the same
TLB instance as it might be used for nesting, and we can have
end-to-end cached entires.
For secure state, I think it’s cleaner to instantiate a new TLB, as
both states can never mix, and in this case we can re-use the same
functions without adding the secure bit in the TLB.
Thanks for the suggestion.
I agree that keeping separate TLB instances per security state is
cleaner and avoids having to carry a sec_sid tag through every cache path.
The only downside is a bit more plumbing: we’ll need to make sure the
translation/PTW paths always pick the right per-bank TLB (otherwise some
call sites may still default to the NS one). This also means touching
the common layer since smmu-common currently assumes a single s->iotlb.
Although some refactoring work is still needed, I’m happy to follow your
approach and will rework this in V5.
Thanks,
Mostafa
Best regards,
Tao
