Re: [RFC v5 15/28] hw/arm/smmu: Make CMDQ invalidation security-state aware
Tao Tang <[email protected]>
| Newsgroups | org.nongnu.qemu-arm,org.nongnu.qemu-devel |
|---|---|
| Message-ID | <[email protected]> |
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 <[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. 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/[email protected]/ [2] https://lore.kernel.org/qemu-devel/[email protected]/ [3] https://lore.kernel.org/qemu-devel/[email protected]/ > Regards, > Pierrick Best regards, Tao