On Sun, Mar 1, 2026 at 3:08 PM Tao Tang <[email protected]> wrote: > > 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. >
I see, I will need to think more about this. My initial thought was that the iotlb seems to be exclusively used in smmu_iotlb_*() So, I was wondering if we can change those functions to pass the iotlb as a function argument. We should have enough context from translation or invalidation paths to pass the correct iotlb instance. But, I agree, it might not be as simple as I imagine, although I think that would be cleaner. I will look more into it. Thanks, Mostafa > > 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 >
