Re: [RFC PATCH v2 00/10] TDX: Stop auto-generating the global metadata code

[Chao Gao]

On Wed, Sep 23, 2026 at 08:44:04AM +0300, Tony Lindgren wrote:
>On Fri, Sep 18, 2026 at 06:29:19AM -0700, Chao Gao wrote:
>> This series cleans up the TDX global metadata code. It has two goals:
>> 
>> 1. Replace the generated code with a table-driven metadata reader.
>> 
>> 2. Make the existing code easier to read and maintain, and simplify
>>    adding new metadata fields.
>> 
>> During the v1 review, Dave raised concerns about signing off on
>> AI-generated code. I have since rewritten the affected patches based on
>> my own understanding of the code.
>> 
>> The main goal of this RFC is to agree on whether the table-driven reader is
>> the right replacement for the generated code. Please raise any concerns or
>> alternative design ideas.
>
>For alternatives, I wonder if grouping the metadata would help in the long
>run. Some of TDX metadata needs to be cached. Some of the metadata is init
>time data for how much memory to allocate etc. Some of the metadata needs
>to be re-read after TDX module update.

I agree that TDX metadata should be cached only when there is a reason to.

And yes, some init-time data is cached even though nothing reads it after
init: max_tdmrs, max_reserved_per_tdmr and the pamt_*_entry_size fields are
only needed while building the TDMRs.

Only the version fields are re-read after a module update. Splitting them
out of struct tdx_sys_info would be a good improvement, so the rest of the
structure could then be __ro_after_init.

These are cleanups that can be done in a separate series.

>
>Should we have the table-driven metadata reader use the TDX module
>metadata directly by default instead of always copying the data? That
>could be used for the init time data. And data could still be cached for
>CPUIDs etc.

The table-driven reader doesn't impose caching. It maps field IDs to
members of whatever structure the caller passes, so the destination can be
a cached global or a stack local. For init-time data, we can read it into a
stack local the same way the handoff class is read in tdx_module_shutdown().