Re: [PATCH v3 12/13] PCI/TSM: support TDI related operations for host TSM driver

[Dan Williams <dan.j.williams@intel.com>]

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@kernel.org
[5]: http://lore.kernel.org/20250311144601.145736-3-suzuki.poulose@arm.com