On 7/6/25 11:56, Dan Williams wrote:
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.
Right, so I need to understand how this TSM makes your life easier. I did show my complete solution, still waiting to see yours or any other really. For example, DOE bouncing.
"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".
Quite a chunk of it is in the SPDM specs which have all sorts of bindings. No strict PCI.
VFIO started as PCI and look at it now with all these platform and mediated devices.
> 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.
That's because I did not do very good job explaining my TSM, my bad, I'll do better, it is too bloated now, and violates sysfs, and should integrate with Lukas'es work, my bad.
But having this all in a single built-in (1) with PCI nailed down (2), globals (3), one tsm_ops struct for both host and guest - this frustrates me.
(1) means annoyingly many reboots vs rmmod+modprobe
(2) TSM does not IDE (the platform calls the IDE library) and does not do DOE (the DOE library should, called by the platform)
(3) bites every time when there are development bugs
(4) leads to ugly "if (tvm_mode())" checks and bugs (when missed), been there, done that with my first TSM, did not like it.
1/2/3/5 are not necessary, do not really make anything simpler and most likely will requite untangling later.
Say, there are assumptions already made for IDE which I believe we do not have to make (like, same number association blocks in all streams) but it is internal IDE detail, can be changed later if needed, but the API is sane so I am ok with the limitations (thanks btw!). But the TSM just is not there yet imho. Hope it all makes sense. Trying now to move to v6.16-rc1 + dmabuf + this series as we speak so you'll hear from me soon :) Thanks,
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
--
Alexey
