Re: [RFC v5 15/28] hw/arm/smmu: Make CMDQ invalidation security-state aware

[Tao Tang <tangtao1634@phytium.com.cn>]

Hi Pierrick,

On 8/21/2026 6:29 AM, Pierrick Bouvier wrote:
> On 8/13/2026 9:25 AM, Tao Tang wrote:
>> Refactor CMDQ invalidation paths to carry security state and apply cache
>> invalidation per sec_sid instead of globally. Add separate helpers for
>> invalidating all entries and for invalidating entries belonging to one
>> valid sec_sid.
>>
>> In smmuv3, propagate the command queue sec_sid and command SSec through
>> CFGI and TLBI handling, and gate VMID use on the stage-2 capability of
>> the selected command queue, including SMMU_S_IDR1.SEL2 for a Secure
>> Command queue.
>>
>> Keep acceleration and IOMMU notifier propagation Non-secure-only.
>> Commands targeting a programming interface other than Non-secure do not
>> reach the accelerated backend or Non-secure notifiers, while Non-secure
>> stage-1 CMD_TLBI_NH_ALL remains forwarded to the host.
>>
>> Include the command queue SEC_SID and target SEC_SID in the relevant
>> invalidation tracepoints.
>>
>> Signed-off-by: Tao Tang <tangtao1634@phytium.com.cn>
>> ---
>>   hw/arm/smmu-common.c         | 100 ++++++++++++++++++++++++++++-
>>   hw/arm/smmuv3-accel-stubs.c  |   6 +-
>>   hw/arm/smmuv3-accel.c        |  30 +++++++--
>>   hw/arm/smmuv3-accel.h        |   6 +-
>>   hw/arm/smmuv3.c              | 121 ++++++++++++++++++++++++++---------
>>   hw/arm/trace-events          |  12 ++--
>>   include/hw/arm/smmu-common.h |   6 ++
>>   7 files changed, 231 insertions(+), 50 deletions(-)
>>
> Given this patch, would that be simpler to have multiple iotlb hashtable
> per sec_sid? This way, invalidation becomes trivial.
>
> It has been long time since last version, so I forgot if there was a
> specific reason to keep a single table and add sec_sid to each entry.


I agree that separate IOTLB tables per SEC_SID would simplify the 
namespace-wide invalidation in the current model. Mostafa made the same 
suggestion in v4 [1], and I agreed to rework it for v5.

As Eric later pointed out [2], SEC_SID is not itself the architectural 
TLB tag. It selects the programming interface and Stream table, while 
cached translations are identified by the effective StreamWorld and the 
applicable ASID/VMID.

My reason for retaining the single table is therefore patch scope, not 
an architectural objection to per-SEC_SID tables. This series models one 
StreamWorld per SEC_SID and uses SEC_SID as a temporary discriminator, 
as described in the definition of struct SMMUIOTLBKey [3]. I would 
prefer to keep the cache topology unchanged here and address the layout 
together with full StreamWorld tagging and invalidation in a follow-up 
series.

Eric, would you prefer that v6 adopt the per-SEC_SID split suggested by 
Pierrick and Mostafa, or keep the current layout and defer the topology 
decision to the StreamWorld work? I am happy to follow the preferred 
direction.

[1] https://lore.kernel.org/qemu-devel/aaGuGuevX8HFqx0x@google.com/
[2] 
https://lore.kernel.org/qemu-devel/72026588-1db3-48a1-af99-e5e2aca69058@redhat.com/
[3] 
https://lore.kernel.org/qemu-devel/20260813162512.2807281-2-tangtao1634@phytium.com.cn/ 



> Regards,
> Pierrick


Best regards,

Tao