Alexey Kardashevskiy wrote: [..] > > but the point is still that we > > have not even got one implementation of a bus Device Security protocol > > upstream, let alone multiple. > > And my point is that TSM does not actually do anything with PCI except > SPDM/DOE which can happily live in a library or DOE (and called from > CCP or TDX drivers) and the rest can be just "device", not "pci_dev". > I wonder if+how nailing TSM to PCI makes your life somehow easier, it > is not going to help my case. Thanks, The goal is not to solve Alexey's case, the goal is to solve the TDISP enabling problem in a way that all impacted subsystem owners (PCI, Device core, DMA, IOMMU, VFIO/IOMMUFD, KVM, CPU arch/...), and all TSM platform vendors are willing to accept. "TSM" is literally a PCI-introduced term. It comes with a full device-model and state machine for a protocol that we, OS practitioners, have a chance to agree what it means. If another bus wants to do "Device Security" ideally it would map as a strict subset of the TDISP model. If / when that happens it is easy enough for userspace to see "oh hey, bus $foo now has tsm/connect and tsm/accept mechanisms too". Just like the evolution of the "new_id / remove_id, and authorized" bus attributes, other buses add workalike functionality as a matter of course. Other buses can add "TSM" mechanisms to their device model, "TSM" is not a device model unto itself. Similarly, nothing stops 'struct pci_dev' properties to be promoted to 'struct device' when needed. I note IOMMMUFD has the bulk of all the interesting cross-bus shared work to do here and it already has a generic device object model for that purpose. It is another example of "extend existing objects with 'Device Security' properties", not "add a new tdi_dev object to manage". I am frustrated that we are still spinning in this philosophical debate. In terms of progress towards the goal of "shared commons that all impacted subsystem owners are willing to accept": * Bjorn acked the PCI/TSM approach [1] * Lukas is doing native CMA and SPDM work that may yield a shared transport for multiple use cases (SPDM/CMA and TDISP) [2] * Greg gave a nod to the PCI/TSM staging approach [3]. * Aneesh and Suzuki are helping out with ideas [4], and fixes to move this forward [5] This is not a competition, this is carrying a shared upstream burden by consensus for the benefit of ecosystem use cases. [1]: http://lore.kernel.org/20240419220729.GA307280@bhelgaas [2]: https://github.com/l1k/linux/commits/doe [3]: http://lore.kernel.org/2024120625-baggage-balancing-48c5@gregkh [4]: http://lore.kernel.org/yq5att5f4osr.fsf@xxxxxxxxxx [5]: http://lore.kernel.org/20250311144601.145736-3-suzuki.poulose@xxxxxxx
