Support emulators implementing device assignment

[pbo-linaro]

At Linaro, we are currently working to support the latest Device Assignment software stack published by Arm with QEMU.
The build and run have been automated here (branch rme_sbsa_device_assignment_v2).
QEMU wip branch is here (branch smmu-da-2026-01-05).

This scenario boots a VM that supports device assignment, then boots a nested VM with a device assigned, that locks it and set it to TDISP run state. The SPDM/TDISP part is implemented by spdm-emu:

spdm_responder_emu --trans PCI_DOE --slot_count 1&
qemu-system-aarch64 -device ahci,id=ahci,spdm_port=2323,bus=root_port ...

Note: In the past, we have been experimenting with libspdm directly, and it was finally chosen to delegate this to spdm-emu.

---

We have been running into various limitations, and would like to start a conversation to see if it would be something that could be enhanced upstream in spdm-emu. We believe it could allow other emulators to use spdm-emu as a reference TDISP implementation also.

1. Socket port option
   Add an option to configure socket port. It would allow to use several spdm_responder_emu for different devices. Seems to be easy to add.
2. device description
   TDISP interface report is used by kernel to know which MMIO regions must be mapped for the device. spdm-emu has a static device, and it would be nice to be able to parameterize it. We have been using this patch to override description.
   Ideally, it should be possible to configure this at runtime and not via command line options.
3. Query device state
   Once the device has been locked and set in Run state, it will start to target a different address space than non secure one (Realm in this case). We need to detect this change on QEMU side. SMMU specification mentions that PCI T bit (3.9.4 SMMU interactions with the PCIe fields T, TE and XT) is used to detect when a device targets targets the Realm address space. If we could poke spdm_responder_emu, this would allow to query state of device, and know when it transitioned.
   A simple solution could be to add a header (with data non encrypted) to communication over socket reflecting this information, so emulator can easily read this and poke current state of device.

Before doing any concrete work on spdm-emu, we would like to know if it's something its community would be open to accept. As well, we would like to know if there has been previous attempts to solve those issues.

Thanks,
Pierrick

[steven-bellock]

1 and 2 are reasonable. 3 might need some discussion. Feel free to make a separate issue for 1 and 2.

Adding @alistair23 and @twilfredo, since they run https://github.com/westerndigitalcorporation/spdm-utils and might have an opinion.

[pbo-linaro]

Thanks for the feedback.
Indeed, we would be interested to know how existing users are dealing with 2 and 3, as it's needed as soon as a real device is modelled.