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

[Tony Lindgren]

On Wed, Sep 23, 2026 at 04:19:12PM +0800, Chao Gao wrote:
> 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.

Yes OK agreed.

> >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().

OK thanks, nice to hear you have already considered the next steps. Might
be worth updating the cover letter for the follow up options too.