From: Chao Gao <chao.gao@intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-coco@lists.linux.dev>,
<kvm@vger.kernel.org>, <rick.p.edgecombe@intel.com>,
<kas@kernel.org>, <dave.hansen@linux.intel.com>
Subject: Re: [PATCH v1 1/8] x86/virt/tdx: Stop treating tdx_global_metadata.h as auto-generated
Date: Wed, 5 Aug 2026 20:06:55 +0800 [thread overview]
Message-ID: <anMnX5Zcje0vAxNf@intel.com> (raw)
In-Reply-To: <43bb043e-8a01-484e-905b-41c73ae835d3@intel.com>
>> Today the header that holds these structures is generated by an
>> out-of-tree script from a JSON file listing all of the TDX module's
>> metadata. That made it trivial to add a new field, but everything
>> else suffered for it:
>>
>> - The header is opaque to anyone who doesn't have the script and
>> the JSON file handy, and the "Automatically generated" tag tells
>> reviewers their edits will be clobbered.
>> - The script ships outside the tree, so reproducing changes
>> requires fetching it from a mailing list link.
>> - The structures are short and stable; the script's value over
>> a hand-edited header is small.
>
>Well, and the big one: after we started doing this, the "ABI Definitions
>for Intel® TDX" was declared to be not an ABI. So, even if we code to
>the JSON, there's no guarantee the JSON will be stable.
>
><sigh>
>
>Honestly that's what matters. The script and all the other fluff is just
>noise.
Thanks for this. So the key point is that auto-generating rests on a
premise: the JSON is the ABI and stays stable. Then regenerating gives
you something you can trust without re-checking. That premise isn't true
now, so we should stop auto-generating.
One thing I'd like to confirm: is the concern that the JSON could be wrong
about what modules actually implement, or just that there's no commitment
to keep the JSON stable? or both?
>
>> Signed-off-by: Chao Gao <chao.gao@intel.com>
>
>So, I'm curious: What made you feel OK to sign-off on this? I'm not
>judging. I'm open-minded on this. All I know is *I* wasn't ready to
>sign-off on this.
>
>I really want to know what your thought process was.
The idea and the implementation looks good to me, and I thought they were
ready for on-list review. As the person who modified and posted the
series, my reading of submitting-patches.rst is that I need to sign off
_any_ patches I posted.
next prev parent reply other threads:[~2026-08-05 12:07 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 11:29 [PATCH v1 0/8] TDX: Stop auto-generating the global metadata code Chao Gao
2026-08-04 11:29 ` [PATCH v1 1/8] x86/virt/tdx: Stop treating tdx_global_metadata.h as auto-generated Chao Gao
2026-08-04 23:43 ` Dave Hansen
2026-08-05 12:06 ` Chao Gao [this message]
2026-08-05 15:26 ` Dave Hansen
2026-08-04 11:29 ` [PATCH v1 2/8] x86/virt/tdx: Name the TDX module global metadata field IDs Chao Gao
2026-08-04 23:52 ` Dave Hansen
2026-08-05 12:45 ` Chao Gao
2026-08-05 17:10 ` Edgecombe, Rick P
2026-08-10 6:35 ` Chao Gao
2026-08-04 11:29 ` [PATCH v1 3/8] x86/virt/tdx: Add a table-driven TDX global metadata reader Chao Gao
2026-08-05 17:48 ` Edgecombe, Rick P
2026-08-10 6:43 ` Chao Gao
2026-08-10 18:32 ` Edgecombe, Rick P
2026-08-04 11:29 ` [PATCH v1 4/8] x86/virt/tdx: Convert version/tdmr/td_ctrl/handoff readers Chao Gao
2026-08-04 11:29 ` [PATCH v1 5/8] x86/virt/tdx: Convert td_conf reader Chao Gao
2026-08-04 11:29 ` [PATCH v1 6/8] x86/virt/tdx: Remove the auto-generated tdx_global_metadata.c Chao Gao
2026-08-04 11:29 ` [PATCH v1 7/8] x86/virt/tdx: Clean up error handling in get_tdx_sys_info() Chao Gao
2026-08-04 11:29 ` [PATCH v1 8/8] x86/virt/tdx: Verify the C member size against the metadata field ID Chao Gao
2026-08-04 23:38 ` [PATCH v1 0/8] TDX: Stop auto-generating the global metadata code Dave Hansen
2026-08-05 12:11 ` Chao Gao
2026-08-05 17:19 ` Edgecombe, Rick P
2026-08-10 8:49 ` Chao Gao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=anMnX5Zcje0vAxNf@intel.com \
--to=chao.gao@intel.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=kas@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=rick.p.edgecombe@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.