On 8/11/25 3:26 AM, Philippe Mathieu-Daudé wrote:
On 10/8/25 18:11, Tao Tang wrote:
On 2025/8/7 05:28, Pierrick Bouvier wrote:
On 8/6/25 8:11 AM, Tao Tang wrote:
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?
This shouldn't be an issue, we already have some:
$ git ls-files|fgrep testdev
chardev/testdev.c
docs/specs/pci-testdev.rst
hw/hyperv/hyperv_testdev.c
hw/misc/pc-testdev.c
hw/misc/pci-testdev.c
hw/tricore/tricore_testdevice.c
Looks good indeed, and we have the TEST_DEVICES category for that.
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.
