Re: [PATCH v4 03/24] coco/tdx-host: Expose TDX Module version

["Huang, Kai" <kai.huang@intel.com>]

On Tue, 2026-02-24 at 10:02 +0800, Chao Gao wrote:
> On Fri, Feb 20, 2026 at 08:40:13AM +0800, Huang, Kai wrote:
> > On Thu, 2026-02-12 at 06:35 -0800, Chao Gao wrote:
> > > For TDX Module updates, userspace needs to select compatible update
> > > versions based on the current module version. This design delegates
> > > module selection complexity to userspace because TDX Module update
> > > policies are complex and version series are platform-specific.
> > > 
> > > For example, the 1.5.x series is for certain platform generations, while
> > > the 2.0.x series is intended for others. And TDX Module 1.5.x may be
> > > updated to 1.5.y but not to 1.5.y+1.
> > > 
> > > Expose the TDX Module version to userspace via sysfs to aid module
> > > selection. Since the TDX faux device will drive module updates, expose
> > > the version as its attribute.
> > > 
> > > One bonus of exposing TDX Module version via sysfs is: TDX Module
> > > version information remains available even after dmesg logs are cleared.
> > > 
> > > == Background ==
> > > 
> > > The "faux device + device attribute" approach compares to other update
> > > mechanisms as follows:
> > 
> > This "faux device + device attribute" approach seems to be a wider design
> > choice instead of how to expose module version (which is the scope of this
> > patch).  Overall, shouldn't this be in the changelog of the previous patch
> > which actually introduces "faux device" (albeit no attribute is introduced
> > in that patch)?
> , 
> Yes, it's mentioned briefly in the previous patch:
> 
> """
> Create a virtual device not only to align with other implementations but
> also to make it easier to
> 
>  - expose metadata (e.g., TDX module version, seamldr version etc) to
>    the userspace as device attributes
> 
>  ...
> """
> 
> The previous patch doesn't provide details for version information
> exposure, as version attributes are just one of several purposes for the
> virtual device.
> 
> > 
> > > 
> > > 1. AMD SEV leverages an existing PCI device for the PSP to expose
> > >    metadata. TDX uses a faux device as it doesn't have PCI device
> > >    in its architecture.
> > 
> > E.g., this sounds to justify "why to use faux device for TDX", but not "to
> > expose module version via faux device attributes".
> 
> This provides additional context as suggested by Dave:
> 
> https://lore.kernel.org/kvm/aa3f026b-ad69-4070-8433-8950e5250edb@intel.com/
> 
> Dave asked:
> 
> """
> What are other CPU vendors doing for this? SEV? CCA? S390? How are their
> firmware versions exposed? What about other things in the Intel world
> like CPU microcode or the billion other chunks of firmware? ...
> """

I fully agree with this.  We need justification of why we need to expose TDX
module version to somewhere in /sysfs, and the choice of that somewhere is
the faux device attributes.

But my interpretation is Dave is asking to provide such justification in
general, but not specifically in _this_ patch.

In this patch, you have already adequately put why to expose version info
via /sysfs.  The "background" is really explaining why to choose "faux
device" as the /sysfs entry.

But you have already made the choice to use faux device (and mentioned
exposing version is one purpose) in the previous patch, so to me the
"background" part is a bit weird to be here, but not in previous patch.

But I also see there's some connection here -- and anyway this is just my
interpretation, so feel free to ignore :-)