On 4/6/25 11:54, Dan Williams wrote:
Dan Williams wrote:
Alexey Kardashevskiy wrote:
On 4/6/25 08:47, Dan Williams wrote:
Suzuki K Poulose wrote:
[..]
Ok, something like this? and iommufd will call tsm_bind()?
Remember that there may be other devices, AMBA CHI based devices
being assigned. Not sure if they pretend to be PCI or not.
I have been thinking about this especially with the relative ease of
creating samples/devsec/ given the existing Linux infrastructure
emulating PCI host bridges.
Why not require PCI emulation for non-PCI devices? The tipping point is
whether the relative maintenance burden of not needing to maintain
multi-bus Device Security infrastructure outweighs the complexity of
impedance matching those other buses to PCI.
Make "PCI" the lingua franca of Device Security.
This is how virtio started, and now it has to behave like a proper PCI
device, i.e. use DMA API. Or ivshmem which maps memory as "PCI" (which
it is not PCI but the guest does not know it) and is deprecated now.
Not the best idea to enforce PCI from day1 imho.
VFIO is a Linux convention. PCIe TDISP is an industry standard protocol.
Oh, sorry you said "virtio" not "vfio",
"virtio" is just not a Linux convention, Windows (at least guests) uses it, and there were even punks developing physical devices implementing virtio, hence the recommendation of iommu_platform=on in QEMU command line for virtio devices.
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,
--
Alexey
