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

[Jason Gunthorpe <jgg@nvidia.com>]

> [ ... 32 lines skipped ... ]
> @@ -676,17 +679,21 @@ Description:	(RO) Return PCI device name of this device's DSM (Device
>  
>  What:		/sys/bus/pci/devices/.../tsm/bound
>  Contact:	linux-coco@lists.linux.dev
> -Description:	(RO) Return the device name of the TSM when the device is in a
> -		TDISP (TEE Device Interface Security Protocol) operational state
> -		(LOCKED, RUN, or ERROR, not UNLOCKED). Bound devices consume
> -		platform TSM resources and depend on the device's configuration
> -		(e.g. BME (Bus Master Enable) and MSE (Memory Space Enable)
> -		among other settings) to remain stable for the duration of the
> -		bound state. This attribute is only visible for devices that
> -		support TDISP operation, and it is only populated after
> -		successful connect and TSM bind. The TSM bind operation is
> -		initiated by VFIO/IOMMUFD. This is a "link" TSM attribute, see
> -		Documentation/ABI/testing/sysfs-class-tsm.
> +Description:	(RO) Return the device name of the TSM when this PCI function
> +		has a successfully initialized TSM-backed vdevice binding, or
> +		an empty line when no such binding exists. The binding is
> +		established through VFIO/IOMMUFD and remains visible until
> +		the provider releases its context during vdevice teardown.
> +		Merely connecting the device to a TSM or acquiring a context
> +		does not establish a binding. Bindings of other functions
> +		managed by the same DSM do not affect this attribute.
> +
> +		This reports the binding lifetime, not the current TDISP
> +		(TEE Device Interface Security Protocol) state. A bound vdevice
> +		may be UNLOCKED, and TDISP lock/unlock transitions do not
> +		change this attribute. This attribute is only visible for
> +		devices that support TDISP operation. This is a "link" TSM
> +		attribute, see Documentation/ABI/testing/sysfs-class-tsm.

Should we just delete this sysfs instead of torturing the code to
implement it?

Why would anyone ever read it? What purpose would it serve to read it?

Leaking the iommufd vdevice outside the iommufd world is a horrible
idea from a lifetime perspective. We should only do it with an
incredibly strong reason. A debugging sysfs should be deleted. We can
create a debugfs around the viommu if that is really important,
somehow I doubt it is..

-- 
Jason