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

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 <[email protected]>
> ---
>  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.

Regards,
Pierrick