On Thu, 2025-09-04 at 11:31 +0100, Jonathan Cameron wrote: [...] > > > At which point QEMU will try to connect to the SPDM server. > > > > @@ -113,7 +113,13 @@ of the default. So the entire QEMU command > > might look like this > > -append "root=/dev/vda console=ttyS0" \ > > -net none -nographic \ > > -drive file=blknvme,if=none,id=mynvme,format=raw \ > > - -device nvme,drive=mynvme,serial=deadbeef,spdm_port=2323 > > + -device > > nvme,drive=mynvme,serial=deadbeef,spdm_port=2323,spdm_trans=doe > > I wonder if, for command line backwards compatibility we should have > a default > of doe if no spdm_trans parameter is provided? Yeah good point, I will add that.
Regards, Wilfred > > > + > > +The `spdm_trans` argument defines the underlying transport type > > that is emulated > > +by QEMU. For an PCIe NVMe controller, both "doe" and "nvme" are > > supported. Where, > > +"doe" does SPDM transport over the PCIe extended capability Data > > Object Exchange > > +(DOE), and "nvme" uses the NVMe Admin Security Send/Receive > > commands to > > +implement the SPDM transport. > > > > .. _DMTF: > > https://www.dmtf.org/standards/SPDM > > diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c > > index df72599bcc..e485e0584e 100644 > > --- a/hw/nvme/ctrl.c > > +++ b/hw/nvme/ctrl.c > > > @@ -9308,6 +9326,7 @@ static const Property nvme_props[] = { > > false), > > DEFINE_PROP_UINT16("mqes", NvmeCtrl, params.mqes, 0x7ff), > > DEFINE_PROP_UINT16("spdm_port", PCIDevice, spdm_port, 0), > > + DEFINE_PROP_SPDM_TRANS_NODEFAULT("spdm_trans", PCIDevice, > > spdm_trans), > > As above. I think a default is appropriate here. > > > DEFINE_PROP_BOOL("ctratt.mem", NvmeCtrl, params.ctratt.mem, > > false), > > DEFINE_PROP_BOOL("atomic.dn", NvmeCtrl, params.atomic_dn, 0), > > DEFINE_PROP_UINT16("atomic.awun", NvmeCtrl, > > params.atomic_awun, 0),
