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

[Aneesh Kumar K . V]

Jason Gunthorpe <jgg@xxxxxxxxxx> writes:

>> [ ... 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@xxxxxxxxxxxxxxx
>> -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..

OK, I will drop support for the "tsm/bound" sysfs attribute.

-aneesh