Re: [PATCH v3 01/13] coco/tsm: Introduce a core device for TEE Security Managers

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Jun 03, 2025 at 05:42:05PM -0700, Dan Williams wrote:
> Jason Gunthorpe wrote:
> > On Thu, May 15, 2025 at 10:47:20PM -0700, Dan Williams wrote:
> > > +static struct class *tsm_class;
> > > +static struct tsm_core_dev {
> > > +	struct device dev;
> > > +} *tsm_core;
> > 
> > This is gross, do we really need to have a global?
> 
> Let me restate the assumptions that led to this, because if we disagree
> there then that is more interesting and may lead to a better solution.
> 
> * The "TSM" (TEE Security Manager) concept in the PCIe TDISP specification
>   and, by implication, all the CC arch implementations, instantiate this
>   platform object / agent as a singleton. There is one TDX Module in
>   SEAM mode, one SEV-SNP CCP firmware context, one RISC-V COVE module
>   etc...
> 
> * PCIe TDISP is the first of potentially a class of confidential
>   computing platform capabilities that span across platforms.
> 
> * There are generally useful details that platform owners want to know,
>   like number of available / in-use PCIe link encryption stream
>   resources, that are suitable to publish in sysfs.
> 
> * Userspace is better served by a static /sys/class/tsm/tsm... path to those
>   common attributes vs trawling through arch-specific sysfs paths. E.g.
>   SEV-SNP device object for their "TSM" is on the PCI bus, the TDX
>   Module device object lives on the "virtual" bus etc...
> 
> So, create a singleton tsm_core_dev to anchor attributes in that
> "cross-TSM" class.

We will be very sad if we need multiple TSMs or TSM flavours (like
PCI, CHI, whatever) down the road as single TSM was baked permanently
into the uapi.

It is far saner to have paths like /sys/class/tsm0/tsm/.. and remove
the global than take the risk that one and only one is the right
answer forever for everyone.

Jason