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. The goal here is not have platform leak "oh, but my bus is special" details throughout the tree vs keep that limited to the PCIe bus adapter drivers for these things that want to speak a TDISP-ish like language. That said it is difficult to speak in the abstract and the proof needs to be in demonstrating that "tipping point" I mention above has been reached. As it is, we already have our hands full with the industry standard mechanism for the foreseeable future.
