On 2025/8/13 02:04, Pierrick Bouvier wrote:
On 8/10/25 9:11 AM, Tao Tang wrote:
On 2025/8/7 05:28, Pierrick Bouvier wrote:
On 8/6/25 8:11 AM, Tao Tang wrote:
Hi all,
This patch series introduces initial support for emulating the Arm
SMMUv3
Secure State.
------------------------------<snip>------------------------------
------------------------------<snip>------------------------------
Secure Register/Command Interface: I set up an OP-TEE + Hafnium
environment. Hafnium's smmuv3_driver_init function was used to test
the secure register I/O and command queue functionality (excluding
translation). As Hafnium assumes larger queue and StreamID sizes than
are practical without TTST support, I temporarily patched Hafnium to
use smaller values, allowing its driver to initialize the emulated
secure SMMU successfully.
Would that be possible to share your changes, and build instructions
for this? While working on SMMU emulation, we finally left this on the
side due to lack of a software stack being able to use secure SMMU, as
we were not aware that Hafnium + op-tee could make use of it.
Hi Pierrick,
Thanks for your interest! I'm very happy to share my work on this. I've
documented the setup process, including our code modifications and the
step-by-step build instructions in this link:
https://hnusdr.github.io/2025/08/09/Test-Secure-SMMU-with-Hafnium-ENG
Thanks for taking the time to assemble all this in a comprehensible
post, I'll give it a try when I have some spare time.
Hi Pierrick,
You're welcome, and please feel free to let me know if you run into any
issues.
The core point of these changes is to enable the SMMUv3 feature in
Hafnium. This leads to numerous read/write operations on SMMUv3 secure
registers and various queue manipulations within the smmuv3_driver_init
function in Hafnium.
However, it's important to note that this initialization process itself
does not initiate any DMA memory access that would trigger the
smmuv3_translate flow.
I understand the difference. It can be tricky to generate specific
translation scenarios, which is where a custom test device can really
help.
Even so, we've devised a method to test the subsequent Secure
Translation Path by leveraging the smmuv3-test platform device. This
approach allows us to verify the entire SMMUv3 flow, from initialization
to translation.
Does it rely on a custom driver integration into an existing firmware
or the kernel?
Secure Translation Path: Since the TF-A SMMUv3 Test Engine does not
support QEMU, and no secure device assignment feature exists yet, I
created a custom platform device to test the secure translation flow.
To trigger the translation logic, I initiated MMIO writes to this
device from within Hafnium. The device's MMIO callback handler then
performed DMA accesses via its IOMMU region, exercising the secure
translation path. While SMMUv3 is typically used for PCIe on
physical SoCs, the architecture allows its use with platform devices
via a stream-id binding in the device tree. The test harness
required some non-standard modifications to decouple the SMMU from
its tight integration with PCIe. The code for this test device is
available for review at [3]. README.md with detailed instructions is
also provided.
I am not sure about the current policy in QEMU for test oriented
devices, but it would be really useful to have something similar
upstream (Note: it's out of the scope of this series).
One challenge working with SMMU emulation is that reproducing setups
and triggering specific code paths is hard to achieve, due to the
indirect use of SMMU feature (through DMA) and the complex software
stack usually involved.
Having something upstream available to work on SMMU emulation, at
least on device side, would be a great addition.
Eric, Peter, is this something that would be acceptable to merge?
Looking ahead, my plan is to refactor the smmuv3-test platform device.
The goal is to make it self-contained within QEMU, removing the current
dependency on Hafnium to trigger its operations. I plan to submit this
as a separate RFC patch series in the next few days.
This is very welcome. Once this is in place, it would be great to add
a new test to make sure things don't regress, and from where we can
iterate.
By self-contained within QEMU, do you mean a QTest based test?
Regards,
Pierrick
Thanks for the follow-up and the great questions.
To answer your question about the custom test driver: yes, the current
implementation of the smmuv3-test device relies on integration with
Hafnium to be triggered.
The test flow is initiated when Hafnium performs an mmio_write32 to the
smmuv3-test device's MMIO space. This triggers the device's read/write
callback in QEMU. Inside this callback, I use address_space_write/read
to first populate the necessary SMMU structures (STEs, CDs, PTEs) in
guest secure memory, and then perform another address_space_write/read
to an IOMMU-protected region of smmuv3-test. It is this final access
that exercises the full secure translation path. So for now, it is
indeed dependent on the Hafnium firmware for debugging.
That brings me to your next point about making the test
"self-contained". My goal is exactly to remove this dependency. I'm
currently exploring ways to achieve this within QEMU—for instance, by
using QMP commands or another monitor interface to replace the
mmio_write32 action that Hafnium currently provides. This is what I
meant by "self-contained": allowing us to test the entire SMMUv3
translation flow relying only on the QEMU emulator itself, without any
specific guest firmware or kernel.
This leads perfectly to your question about QTest. I'm not very familiar
with it, so your suggestion is very helpful. Is QTest the standard or
required framework for implementing this kind of self-contained test
device? I would appreciate any guidance or pointers you could provide on
this topic.
Thanks again for the valuable discussion.
Best regards,
Tao
