Re: [PATCH v3 01/10] x86/virt/tdx: Add a helper to read a table of metadata fields

[Edgecombe, Rick P]

On Tue, 2026-09-29 at 22:38 -0700, Chao Gao wrote:
> The metadata field readers get_tdx_sys_info_<class>() in
> tdx_global_metadata.c were generated by an out-of-tree script. That has
> not worked out: the JSON file they were generated from is neither stable
> nor authoritative enough [1].  The goal now is to maintain the readers by
> hand and to establish one standard way of adding a metadata field.
> 
> Take get_tdx_sys_info_version() as an example:
> 
>       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;
> 
> Two patterns stand out: the read-check-store sequence repeats once per
> field, and the error of each read is chained into the reads that follow.
> Neither is common in hand-written code.
> 
> Prepare to eliminate both with a loop that reads each field, stores the
> value into its structure member, and returns on the first error.
> 
> Add 'struct field_mapping' to describe one field as its ID plus the offset
> and size of the member that receives its value. Add TDX_SYSINFO_MAP() to
> build such an entry from a field ID, a structure type and a member name.
> Add __read_sys_metadata_table() helper to read every field in a table.
> Annotate that helper __maybe_unused as there is no caller right now.
> 
> Following changes will convert the existing readers to use the new helper.
> 
> AI was used under supervision to review code and workshop logs. It
> suggested adding read_sys_metadata_table() macro, which avoids repeating
> the table name when passing both the table and its size.
> 
> Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
> Link: https://lore.kernel.org/kvm/1e7bcbad-eb26-44b7-97ca-88ab53467212@xxxxxxxxx/ # [1]

Reviewed-by: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>