[ add Lukas ] Giani, Dhaval wrote: > [AMD Official Use Only - General] > > Hi all, > > We have proposed a trusted I/O BoF session at KVM forum this year. I wanted > to kick off the discussion to maximize the 25 mins we have. > > By trusted I/O, I mean using TDISP to have “trusted” communications with a > device using something like AMD SEV-TIO [1] or Intel’s TDX connect [2]. > > Some topics we would like to discuss are > o What is the device model like? > o Do we enlighten the PCI subsystem? > o Do we enlighten device drivers? One observation in relation to these first questions is something that has been brewing since SPDM and IDE were discussed at Plumbers 2022. https://lpc.events/event/16/contributions/1304/ Namely, that there is value in the base specs on the way to the full vendor TSM implementations. I.e. that if the Linux kernel can aspire to the role of a TSM it becomes easier to incrementally add proxying to a platform TSM later. In the meantime, platforms and endpoints that support CMA / SPDM and PCIe/CXL IDE but not full "trusted I/O" still gain incremental benefit. The first proof point for that idea is teaching the PCI core to perform CMA / SPDM session establishment and provide that result to drivers. That is what Lukas has been working on after picking up Jonathan's initial SPDM RFC. I expect the discussion on those forthcoming patches starts to answer device-model questions around attestation. > o What does the guest need to know from the device? > o How does the attestation workflow work? > o Generic vs vendor specific TSMs > > Some of these topics may be better suited for LPC, Maybe, but there's so much to discuss that the more opportunities to collaborate on the details the better. > however we want to get the discussion going from the KVM perspective > and continue wider discussions at LPC. While I worry that my points above are more suited to something like a PCI Micro-conference than a KVM BoF, I think the nature of "trusted I/O" requires those tribes to talk more to each other.
