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.
However, after spelling all that out it occurs to me that a class dev
already meets most of that requirement. The name of the class dev does
not matter much, and other paths can enforce that there is only one TSM
class dev registered at a time.
So userspace could lookup /sys/class/tsm/*/$attribute and as long that
is a single result, great. If that ever returns more than one instance
then we will have entered some advanced future where there are multiple
TSMs per platform.
