From: Chao Gao <chao.gao@intel.com>
Each TDX module has several bits of metadata about which specific TDX
module it is. The primary bit of info is the version, which has an x.y.z
format. These represent the major version, minor version, and update
version respectively. Knowing the running TDX Module version is valuable
for bug reporting and debugging. Note that the module does expose other
pieces of version-related metadata, such as build number and date. Those
aren't retrieved for now, that can be added if needed in the future.
Retrieve the TDX Module version using the existing metadata reading
interface. Later changes will expose this information. The metadata
reading interfaces have existed for quite some time, so this will work
with older versions of the TDX module as well - i.e. this isn't a new
interface.
As a side note, the global metadata reading code was originally set up
to be auto-generated from a JSON definition [1]. However, later [2] this
was found to be unsustainable, and the autogeneration approach was
dropped in favor of just manually adding fields as needed (e.g. as in
this patch).
Signed-off-by: Chao Gao <chao.gao@intel.com>
Link: https://lore.kernel.org/kvm/CABgObfYXUxqQV_FoxKjC8U3t5DnyM45nz5DpTxYZv2x_uFK_Kw@mail.gmail.com/ # [1]
Link: https://lore.kernel.org/all/1e7bcbad-eb26-44b7-97ca-88ab53467212@intel.com/ # [2]
Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
Cc: Kai Huang <kai.huang@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Kiryl Shutsemau <kas@kernel.org>
Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
arch/x86/include/asm/tdx_global_metadata.h | 7 +++++++
arch/x86/virt/vmx/tdx/tdx_global_metadata.c | 16 ++++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/arch/x86/include/asm/tdx_global_metadata.h b/arch/x86/include/asm/tdx_global_metadata.h
index 060a2ad744bff..40689c8dc67eb 100644
--- a/arch/x86/include/asm/tdx_global_metadata.h
+++ b/arch/x86/include/asm/tdx_global_metadata.h
@@ -5,6 +5,12 @@
#include <linux/types.h>
+struct tdx_sys_info_version {
+ u16 minor_version;
+ u16 major_version;
+ u16 update_version;
+};
+
struct tdx_sys_info_features {
u64 tdx_features0;
};
@@ -35,6 +41,7 @@ struct tdx_sys_info_td_conf {
};
struct tdx_sys_info {
+ struct tdx_sys_info_version version;
struct tdx_sys_info_features features;
struct tdx_sys_info_tdmr tdmr;
struct tdx_sys_info_td_ctrl td_ctrl;
diff --git a/arch/x86/virt/vmx/tdx/tdx_global_metadata.c b/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
index 13ad2663488b1..0454124803f36 100644
--- a/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
+++ b/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
@@ -7,6 +7,21 @@
* Include this file to other C file instead.
*/
+static int get_tdx_sys_info_version(struct tdx_sys_info_version *sysinfo_version)
+{
+ int ret = 0;
+ u64 val;
+
+ if (!ret && !(ret = read_sys_metadata_field(0x0800000100000003, &val)))
+ sysinfo_version->minor_version = val;
+ if (!ret && !(ret = read_sys_metadata_field(0x0800000100000004, &val)))
+ sysinfo_version->major_version = val;
+ if (!ret && !(ret = read_sys_metadata_field(0x0800000100000005, &val)))
+ sysinfo_version->update_version = val;
+
+ return ret;
+}
+
static int get_tdx_sys_info_features(struct tdx_sys_info_features *sysinfo_features)
{
int ret = 0;
@@ -89,6 +104,7 @@ static int get_tdx_sys_info(struct tdx_sys_info *sysinfo)
{
int ret = 0;
+ ret = ret ?: get_tdx_sys_info_version(&sysinfo->version);
ret = ret ?: get_tdx_sys_info_features(&sysinfo->features);
ret = ret ?: get_tdx_sys_info_tdmr(&sysinfo->tdmr);
ret = ret ?: get_tdx_sys_info_td_ctrl(&sysinfo->td_ctrl);
--
2.52.0On Fri, Jan 09, 2026 at 12:14:30PM -0700, Vishal Verma wrote: > From: Chao Gao <chao.gao@intel.com> > > Each TDX module has several bits of metadata about which specific TDX > module it is. The primary bit of info is the version, which has an x.y.z > format. These represent the major version, minor version, and update > version respectively. Knowing the running TDX Module version is valuable > for bug reporting and debugging. Note that the module does expose other > pieces of version-related metadata, such as build number and date. Those > aren't retrieved for now, that can be added if needed in the future. > > Retrieve the TDX Module version using the existing metadata reading > interface. Later changes will expose this information. The metadata > reading interfaces have existed for quite some time, so this will work > with older versions of the TDX module as well - i.e. this isn't a new > interface. This is great to have for debugging, if not too late: Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
On 1/10/2026 3:14 AM, Vishal Verma wrote:
> From: Chao Gao <chao.gao@intel.com>
>
> Each TDX module has several bits of metadata about which specific TDX
> module it is. The primary bit of info is the version, which has an x.y.z
> format. These represent the major version, minor version, and update
> version respectively. Knowing the running TDX Module version is valuable
> for bug reporting and debugging. Note that the module does expose other
> pieces of version-related metadata, such as build number and date. Those
> aren't retrieved for now, that can be added if needed in the future.
>
> Retrieve the TDX Module version using the existing metadata reading
> interface. Later changes will expose this information. The metadata
> reading interfaces have existed for quite some time, so this will work
> with older versions of the TDX module as well - i.e. this isn't a new
> interface.
>
> As a side note, the global metadata reading code was originally set up
> to be auto-generated from a JSON definition [1]. However, later [2] this
> was found to be unsustainable, and the autogeneration approach was
> dropped in favor of just manually adding fields as needed (e.g. as in
> this patch).
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
>
> Signed-off-by: Chao Gao <chao.gao@intel.com>
> Link: https://lore.kernel.org/kvm/CABgObfYXUxqQV_FoxKjC8U3t5DnyM45nz5DpTxYZv2x_uFK_Kw@mail.gmail.com/ # [1]
> Link: https://lore.kernel.org/all/1e7bcbad-eb26-44b7-97ca-88ab53467212@intel.com/ # [2]
> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Cc: Kai Huang <kai.huang@intel.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Reviewed-by: Kiryl Shutsemau <kas@kernel.org>
> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> ---
> arch/x86/include/asm/tdx_global_metadata.h | 7 +++++++
> arch/x86/virt/vmx/tdx/tdx_global_metadata.c | 16 ++++++++++++++++
> 2 files changed, 23 insertions(+)
>
> diff --git a/arch/x86/include/asm/tdx_global_metadata.h b/arch/x86/include/asm/tdx_global_metadata.h
> index 060a2ad744bff..40689c8dc67eb 100644
> --- a/arch/x86/include/asm/tdx_global_metadata.h
> +++ b/arch/x86/include/asm/tdx_global_metadata.h
> @@ -5,6 +5,12 @@
>
> #include <linux/types.h>
>
> +struct tdx_sys_info_version {
> + u16 minor_version;
> + u16 major_version;
> + u16 update_version;
> +};
> +
> struct tdx_sys_info_features {
> u64 tdx_features0;
> };
> @@ -35,6 +41,7 @@ struct tdx_sys_info_td_conf {
> };
>
> struct tdx_sys_info {
> + struct tdx_sys_info_version version;
> struct tdx_sys_info_features features;
> struct tdx_sys_info_tdmr tdmr;
> struct tdx_sys_info_td_ctrl td_ctrl;
> diff --git a/arch/x86/virt/vmx/tdx/tdx_global_metadata.c b/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
> index 13ad2663488b1..0454124803f36 100644
> --- a/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
> +++ b/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
> @@ -7,6 +7,21 @@
> * Include this file to other C file instead.
> */
>
> +static int get_tdx_sys_info_version(struct tdx_sys_info_version *sysinfo_version)
> +{
> + int ret = 0;
> + u64 val;
> +
> + if (!ret && !(ret = read_sys_metadata_field(0x0800000100000003, &val)))
> + sysinfo_version->minor_version = val;
> + if (!ret && !(ret = read_sys_metadata_field(0x0800000100000004, &val)))
> + sysinfo_version->major_version = val;
> + if (!ret && !(ret = read_sys_metadata_field(0x0800000100000005, &val)))
> + sysinfo_version->update_version = val;
> +
> + return ret;
> +}
> +
> static int get_tdx_sys_info_features(struct tdx_sys_info_features *sysinfo_features)
> {
> int ret = 0;
> @@ -89,6 +104,7 @@ static int get_tdx_sys_info(struct tdx_sys_info *sysinfo)
> {
> int ret = 0;
>
> + ret = ret ?: get_tdx_sys_info_version(&sysinfo->version);
> ret = ret ?: get_tdx_sys_info_features(&sysinfo->features);
> ret = ret ?: get_tdx_sys_info_tdmr(&sysinfo->tdmr);
> ret = ret ?: get_tdx_sys_info_td_ctrl(&sysinfo->td_ctrl);
>
On 1/10/2026 3:14 AM, Vishal Verma wrote:
> From: Chao Gao <chao.gao@intel.com>
>
> Each TDX module has several bits of metadata about which specific TDX
> module it is. The primary bit of info is the version, which has an x.y.z
> format. These represent the major version, minor version, and update
> version respectively. Knowing the running TDX Module version is valuable
> for bug reporting and debugging. Note that the module does expose other
> pieces of version-related metadata, such as build number and date. Those
> aren't retrieved for now, that can be added if needed in the future.
>
> Retrieve the TDX Module version using the existing metadata reading
> interface. Later changes will expose this information. The metadata
> reading interfaces have existed for quite some time, so this will work
> with older versions of the TDX module as well - i.e. this isn't a new
> interface.
>
> As a side note, the global metadata reading code was originally set up
> to be auto-generated from a JSON definition [1]. However, later [2] this
> was found to be unsustainable, and the autogeneration approach was
> dropped in favor of just manually adding fields as needed (e.g. as in
> this patch).
>
> Signed-off-by: Chao Gao <chao.gao@intel.com>
> Link: https://lore.kernel.org/kvm/CABgObfYXUxqQV_FoxKjC8U3t5DnyM45nz5DpTxYZv2x_uFK_Kw@mail.gmail.com/ # [1]
> Link: https://lore.kernel.org/all/1e7bcbad-eb26-44b7-97ca-88ab53467212@intel.com/ # [2]
> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Cc: Kai Huang <kai.huang@intel.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Reviewed-by: Kiryl Shutsemau <kas@kernel.org>
> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Though one nit below,
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
> ---
> arch/x86/include/asm/tdx_global_metadata.h | 7 +++++++
> arch/x86/virt/vmx/tdx/tdx_global_metadata.c | 16 ++++++++++++++++
> 2 files changed, 23 insertions(+)
>
> diff --git a/arch/x86/include/asm/tdx_global_metadata.h b/arch/x86/include/asm/tdx_global_metadata.h
> index 060a2ad744bff..40689c8dc67eb 100644
> --- a/arch/x86/include/asm/tdx_global_metadata.h
> +++ b/arch/x86/include/asm/tdx_global_metadata.h
> @@ -5,6 +5,12 @@
>
> #include <linux/types.h>
>
> +struct tdx_sys_info_version {
> + u16 minor_version;
> + u16 major_version;
Nit, not sure if better to move major_version before minor_version.
and ...
> +static int get_tdx_sys_info_version(struct tdx_sys_info_version *sysinfo_version)
> +{
> + int ret = 0;
> + u64 val;
> +
> + if (!ret && !(ret = read_sys_metadata_field(0x0800000100000003, &val)))
> + sysinfo_version->minor_version = val;
> + if (!ret && !(ret = read_sys_metadata_field(0x0800000100000004, &val)))
> + sysinfo_version->major_version = val;
> + if (!ret && !(ret = read_sys_metadata_field(0x0800000100000005, &val)))
> + sysinfo_version->update_version = val;
... I know it's because minor_version has the least field ID among the
three. But the order of the field IDs doesn't stand for the order of the
reading. Reading the middle part y of x.y.z as first step looks a bit odd.
On 1/11/26 18:25, Xiaoyao Li wrote: > ... I know it's because minor_version has the least field ID among the > three. But the order of the field IDs doesn't stand for the order of the > reading. Reading the middle part y of x.y.z as first step looks a bit odd. I wouldn't sweat it either way. Reading 4, 3, 5 would also look odd. I'm fine with it as-is in the patch.
On Mon, Jan 12, 2026 at 06:56:58AM -0800, Dave Hansen wrote: > On 1/11/26 18:25, Xiaoyao Li wrote: > > ... I know it's because minor_version has the least field ID among the > > three. But the order of the field IDs doesn't stand for the order of the > > reading. Reading the middle part y of x.y.z as first step looks a bit odd. > > I wouldn't sweat it either way. Reading 4, 3, 5 would also look odd. I'm > fine with it as-is in the patch. I prefer 3, 4, 5. The field IDs are not human readable hex magic so should take extra care when copying from excel file to C file manually, A different list order would make the code adding & reviewing even harder. >
On 1/13/2026 10:56 AM, Xu Yilun wrote: > On Mon, Jan 12, 2026 at 06:56:58AM -0800, Dave Hansen wrote: >> On 1/11/26 18:25, Xiaoyao Li wrote: >>> ... I know it's because minor_version has the least field ID among the >>> three. But the order of the field IDs doesn't stand for the order of the >>> reading. Reading the middle part y of x.y.z as first step looks a bit odd. >> >> I wouldn't sweat it either way. Reading 4, 3, 5 would also look odd. I'm >> fine with it as-is in the patch. > > I prefer 3, 4, 5. The field IDs are not human readable hex magic so > should take extra care when copying from excel file to C file manually, > A different list order would make the code adding & reviewing even > harder. I guess eventually we will introduce MACROs for these magic numbers to make the code more readable given that the decision is no longer auto-generate the code by the script? Though I'm not sure when that will happen.
© 2016 - 2026 Red Hat, Inc.