Alexey Kardashevskiy wrote:
[..]
> > +struct pci_tsm_ops {
> > + /*
> > + * struct pci_tsm_link_ops - Manage physical link and the TSM/DSM session
> > + * @probe: allocate context (wrap 'struct pci_tsm') for follow-on link
> > + * operations
> > + * @remove: destroy link operations context
> > + * @connect: establish / validate a secure connection (e.g. IDE)
> > + * with the device
> > + * @disconnect: teardown the secure link
> > + *
> > + * Context: @probe, @remove, @connect, and @disconnect run under
> > + * pci_tsm_rwsem held for write to sync with TSM unregistration and
> > + * mutual exclusion of @connect and @disconnect. @connect and
> > + * @disconnect additionally run under the DSM lock (struct
> > + * pci_tsm_pf0::lock) as well as @probe and @remove of the subfunctions.
> > + */
> > + struct_group_tagged(pci_tsm_link_ops, link_ops,
> > + struct pci_tsm *(*probe)(struct pci_dev *pdev);
>
>
> struct pci_tsm *(*probe)(struct pci_dev *pdev, struct tsm_dev *tsm)
>
> as otherwise there is no way to get from pci_dev to tsm_dev (which is sev_device - that thing with request/response buffers for guest requests, etc).
Oh, good point. My sample driver was still stuck in the TSM singleton
universe, indeed this needs to pass the tsm_dev will add, same for
->lock().
> Or add a simple void* to tsm_register() and pci_tsm_ops::probe().
No, let's not give up type-safety unnecessarily.
> Or I can add (which way?) and maintain in my tree. Thanks,
As mentioned in the cover letter for the past few revisions I still have
an open invitation and hope that tsm.git / kernel.org gets to a point
where multiple vendors kernel and VMM trees are unified. So I will spin
an urgent incremental fixup for this, rebase #staging and post a new
devsec-20250828 tag.
I think the shared staging tree will be needed because of the long road
ahead on coming to consensus on all the DMABUF/VFIO/IOMMUFD ABI
concerns. I also want to show 2 vendors merged in that tree before
asking upstream to merge any of this.
If we can get the PCI/TSM core stabilized (2 vendors) and the guest side
encrypted MMIO and DMA details settled (including device-core changes) I
would feel comfortable pushing that upstream while letting the VMM side
ABI discussions continue.
