Re: [RFC v5 00/28] hw/arm/smmuv3: Support Secure state for SMMUv3

Hi Pierrick,

On 8/21/2026 6:16 AM, Pierrick Bouvier wrote:
> On 8/13/2026 9:15 AM, Tao Tang wrote:
>> Hi all,
>>
>> This is v5 of the Secure SMMUv3 series.
>>
>> Many thanks to everyone who reviewed the earlier versions. This version contains
>> 28 commits in total. Only one patch touches hw/pci (patch #23); the remaining
>> patches are confined to the Arm SMMUv3 model. Also some patches in v4 have been
>> merged into the mainline QEMU tree, so the v5 series is now smaller than v4.
>>
>> Secure Stage 2 is not implemented. Secure STEs which enable Stage 2 are
>> rejected with C_BAD_STE. Realm and Root programming interfaces are outside the
>> scope of this series.
>>
>> Commits layout:
>> ---------------
>> The commits are roughly grouped as follows:
>> 1. (#23, hw/pci only) Add a PCIDevice "sec-sid" property so boards can mark a
>>    device's SEC_SID (system integration knob).
>> 2. (#1-2, #24-27) Core data-structure and plumbing refactors.
>> 3. (#3-8) Introduce SEC_SID through caches, notifiers, and helpers.
>> 4. (#9-12) Page table walk related updates (e.g. NSCFG/PTE helpers).
>> 5. (#13-15) EVTQ/CMDQ handling and invalidation paths.
>> 6. (#16-22) MMIO/register access checks and architectural corner cases.
>> 7. (#28) A temporary [NOT-MERGE] commit used with Hafnium to exercise
>>    secure-bank register access.
>>
>>
>> Main updates:
>> -------------
>> - (#23, hw/pci only) Add a "sec-sid" property to PCIDevice and consume it from
>>    the SMMU in #24 to select the security context and validate capabilities.
>>
>>    @Michael: could you please review the hw/pci change
>>    ("hw/pci: Add sec-sid property to PCIDevice") and confirm this kind of
>>    system-integration property is acceptable for the PCI subtree?
>>
>>    For context, I previously posted this as a standalone patch [1]:
>>    [1] https://lore.kernel.org/qemu-devel/[email protected]/
>>
>>    The commit in this v5 series is an updated version based on Pierrick's
>>    feedback (notably switching sec-sid to a string property). We also discussed
>>    the need for this knob as a prerequisite for accurately modelling SMMU secure
>>    state here [2]:
>>
>>    [2] https://lore.kernel.org/qemu-devel/[email protected]/
>>
>>    We do need a stable way for boards to statically mark devices that may issue
>>    Secure transactions.
>>
>> other updates:
>> - Drop the CR0 and CFGI_CD fixes which are already upstream.
>> - Select MemTxAttrs and AddressSpace on demand from SEC_SID and keep the
>>    programming-interface namespace in the configuration and IOTLB keys.
>> - Route CMDQ, EventQ, IRQ and GERROR handling through the originating
>>    programming-interface bank.
>> - Tighten MMIO RAZ/WI, writability and reserved-bit handling.
>> - Reject unsupported non-NS IOMMU notifier registration.
>> - Make secure-impl an on/off/auto property, resolve auto from the Secure
>>    AddressSpace, and require Stage 1 support when enabled.
>>
>>
>> Testing notes:
>> --------------
>> - Testing MMIO accesses
>>    The branch currently contains one commit explicitly marked [NOT-MERGE]. It is
>>    only used to cooperate with Hafnium to exercise and validate secure-bank
>>    register read/write paths in a small, reproducible setup as described in [3]:
>>    [3] https://hnusdr.github.io/2025/08/09/Test-Secure-SMMU-with-Hafnium-ENG/
>>
>>    This commit is not intended for upstream and will be dropped before posting
>>    the final mergeable series.
>>
>>    For reference, the Hafnium test logs show the SMMU being initialized
>>    successfully:
>>
>>    INFO: Loading VM id 0x8001: op-tee.
>>    INFO: Loaded with 4 vCPUs, entry at 0xe300000.
>>    INFO: Hafnium initialisation completed
>>
> If anyone wants to reproduce it, you can file a precompiled archive
> (with optee + hafnium):
>
> $ wget
> https://github.com/p-b-o/qemu-linux-stack/releases/download/build/optee-secure-smmu-10674a1.tar.xz
> $ tar xvf optee-secure-smmu*
> $ ./run.sh ./build/qemu-system-aarch64
>   With current master branch:
> INFO: Initializing Hafnium (SPMC)
> ...
> ERROR: SMMUv3 does not implement secure state
> ERROR: SMMUv3: Failed to initialize driver
> Panic: Could not initialize IOMMUs.
>
> With this series applied:
> INFO: Initializing Hafnium (SPMC)
> ...
> INFO: Arm SMMUv3 initialized
> ...
> INFO: Loading VM id 0x8001: op-tee.
> INFO: Loaded with 4 vCPUs, entry at 0xe300000.
> INFO: Hafnium initialisation completed
>
> Tested-by: Pierrick Bouvier <[email protected]>


Thanks for testing and for providing the prebuilt archive.

Building Hafnium locally is still not very straightforward, as it 
requires a specific toolchain, several build dependencies, and some code 
patches. So the archive is especially helpful.


> Regards,
> Pierrick


Best regards,

Tao