Re: [RFC PATCH v6 11/11] PCI/TSM: Add reference-counted contexts for vdevice providers

[Jason Gunthorpe]

On Fri, Oct 02, 2026 at 11:44:15AM +0530, Aneesh Kumar K.V wrote:
> Jason Gunthorpe <jgg@xxxxxxxx> writes:
> 
> > On Tue, Sep 29, 2026 at 12:17:30AM +0530, Sonang Patel wrote:
> >> On Thu, 17 Sep 2026 19:31:59 +0530, Aneesh Kumar K.V (Arm) wrote:
> >> > +		if (is_pci_tsm_pf0(pdev)) {
> >> > +			if (pci_tsm_disconnect(pdev))
> >> > +				pci_warn(pdev, "TSM connection is still in use\n");
> >> > +		} else {
> >> > +			tsm_remove(pdev->tsm);
> >> > +		}
> >> 
> >> What happens if the PCI device is removed (e.g. sysfs remove, surprise
> >> hot-unplug) while the vDEVICE/TDI still exists?
> >> Since removal cannot be refused, should the remove path still force
> >> the unbind/unlock?
> >
> > vfio prevents that. It currently will block the sysfs remove until
> > vfio is closed.
> 
> This came up during a Codex review of my patch set. The question is what
> happens if function 1 is assigned to the guest and function 0 is then
> removed through sysfs. Is that allowed? 

It can happen and I don't know we can do anything to prevent it.

> If so, it could be a problem because function 1 is not unbound and
> can continue to be used, while
> removing function 0 tears down DOE and IDE via:
> 
> 	pci_doe_destroy(dev);
> 	pci_ide_destroy(dev);

Ah, PCI sig keeps on giving..

The actual measurements are per function but the SPDM channel is per
device!

At least for RMM is this a problem? It looks like the spec handles
this case the function 0 destroys IDE and commands related to the
other functions will just start failing.

So I would expect the OS implementation here to have similar
properties that even though function 0 is gone the other functions
still 'work' in that they get the RMM defined failures for these
conditions.

Basically, this shouldn't result in a TSM hot unplug of function
1.. Trying to do multi-device operations is always a locking mess it
should be avoided.

Jason