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
