On Tue, 7 May 2024 16:46:29 +0800
Xu Yilun <yilun.xu@xxxxxxxxxxxxxxx> wrote:
> > > > +
> > > > +/* collect TSM capable devices to rendezvous with the tsm
> > > > driver */ +static DEFINE_XARRAY(pci_tsm_devs);
> > >
> > > imho either this or pci_dev::tsm is enough but not necessarily
> > > both.
> >
> > You mean:
> >
> > s/pci_tsm_devs/tsm_devs/
> >
> > ?
>
> I don't think the concern is just a renaming. My understanding is, we
> already have a struct pci_tsm embedded in struct pci_dev, we could
> loop and find all TSM capable devices by:
>
> for_each_pci_dev(pdev) {
> if (pdev->tsm)
> pci_tsm_add/del(pdev);
> }
>
> A dedicated list for TSM capable devices seems not necessary.
>
> But my concern is about VFs. VFs are as well TSM capable but not
> applicable for tsm_ops->exec(TSM_EXEC_CONNECT), maybe not applicable
> for tsm_ops->add() either. One way to distinguish PF/VFs is we only
> collect PFs in pci_tsm_devs, but all TSM capable devices have
> valid pci_dev::tsm pointer.
>
> TSM capable devices in Guest should not been collected in pci_tsm_devs
> either.
What is the plan for the TSM capable devices in the guest?
My current understanding is there would be host TSM driver and guest
TSM driver, or a vendor TSM driver will have a host mode and a guest
mode due to its nature to understand if it is running in host or a
guest. They will be plugged into the same framework here.
If that is the case, the TSM driver should step in and decide if a
PF/VF can be managed(added) according to its mode. Maybe TSM driver
should also indicate what tdi_verbs it supports. E.g. in the guest
mode, it tells CONNECT is not available but the device can be managed
by the TSM driver.
Thanks,
Zhi.
>
> Thanks,
> Yilun
>
