Re: [RFC PATCH v1 1/3] x86/tdx: Make TDX metadata available via SYSFS

[Dan Williams]

Kirill A . Shutemov wrote:
[..]
> > > Dan, could you elaborate on what is actual proposal? I am not sure I
> > > understand what 'struct device' can have info on TDX module version be
> > > attached to it.
> > 
> > Confused, you do not understand that devices can have sysfs attributes?
> 
> I didn't understand what device it would be in TDX case.

Oh, *which* device, now I understand the disconnect.

> > Documentation/ABI/testing/sysfs-driver-ccp describes a device object and
> > sysfs attributes for SEV-SNP firmware status.
> > 
> > For TDX, the proposal is to create virtual device to stand in for the
> > lack of a PCI device that fills the same role as AMD PSP.
> 
> Okay, I got it.
> 
> Do you see a problem having the same interface for both host and guest?
> We obviously need indication what level we are running on.

While I see no problem with /sys/devices/virtual/tdx appearing in both
host and guest, that needs to be reconciled with the fact that both
SEV-SNP and TDX created misc devices in the guest.

As for conveying level, the configs-tsm (soon to be renamed
configs-tsm-report) ABI already conveys the level for SEV-SNP if you are
talking about VMPL. 

> > With the expectation that all TSM technolgies (SEV-SNP, TDX, CCA, etc)
> > register a device, udev rules can trigger off a common class device
> > uevent. That proposal is detailed here [1]:
> > 
> > [1]: http://lore.kernel.org/174107247268.1288555.9365605713564715054.stgit@xxxxxxxxxxxxxxxxxxxxxxxxx
> 
> Joerg, what do you think? How does it fit your ideas for SEV-SNP?

As I noted, both technologies currently register guest misc devices, so
natural place for some simple guest side vendor-specific sysfs
attributes would be via the @groups property of 'struct miscdevice'.
Otherwise, the proposal for cross-vendor TSM sysfs interface is via a
/sys/class/tsm device. For now I only have patches for the host side of
that for generically conveying which PCI devices are consuming link
encryption resources in the platform TSM.