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

[Aneesh Kumar K.V <aneesh.kumar@kernel.org>]

Jason Gunthorpe <jgg@ziepe.ca> 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? 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);


>
> If we ever decide to fix that then vfio would have to tear down the
> iommufd vdevice before allowing itself to be destroyed.
>
> We don't need any lifetime nonsense once we are inside an iommufd
> context, its existing locking scheme is very strong already. tsm
> should not be allowed to change while a driver is bound, and basically
> I shouldn't see any refcounting or locking in any of these paths
> stemming from a bound driver context in iommufd.
>

-aneesh