From: "Huang, Kai" <kai.huang@intel.com>
To: "nik.borisov@suse.com" <nik.borisov@suse.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
"bp@alien8.de" <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"seanjc@google.com" <seanjc@google.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>,
"Yamahata, Isaku" <isaku.yamahata@intel.com>
Subject: Re: [PATCH 6/9] x86/virt/tdx: Start to track all global metadata in one structure
Date: Tue, 18 Jun 2024 23:54:28 +0000 [thread overview]
Message-ID: <ed0aee511389e7ce52b5b6d390d12ccbd346cfb4.camel@intel.com> (raw)
In-Reply-To: <54324a46-a196-4e6e-a623-b4bf39cbb5a6@suse.com>
On Tue, 2024-06-18 at 16:17 +0300, Nikolay Borisov wrote:
>
> On 16.06.24 г. 15:01 ч., Kai Huang wrote:
> > The TDX module provides a set of "global metadata fields". They report
> > things like TDX module version, supported features, and fields related
> > to create/run TDX guests and so on.
> >
> > Currently the kernel only reads "TD Memory Region" (TDMR) related fields
> > for module initialization. There are immediate needs which require the
> > TDX module initialization to read more global metadata including module
> > version, supported features and "Convertible Memory Regions" (CMRs).
> >
> > Also, KVM will need to read more metadata fields to support baseline TDX
> > guests. In the longer term, other TDX features like TDX Connect (which
> > supports assigning trusted IO devices to TDX guest) may also require
> > other kernel components such as pci/vt-d to access global metadata.
> >
> > To meet all those requirements, the idea is the TDX host core-kernel to
> > to provide a centralized, canonical, and read-only structure for the
> > global metadata that comes out from the TDX module for all kernel
> > components to use.
> >
> > As the first step, introduce a new 'struct tdx_sysinfo' to track all
> > global metadata fields.
> >
> > TDX categories global metadata fields into different "Class"es. E.g.,
> > the current TDMR related fields are under class "TDMR Info". Instead of
> > making 'struct tdx_sysinfo' a plain structure to contain all metadata
> > fields, organize them in smaller structures based on the "Class".
> >
> > This allows those metadata fields to be used in finer granularity thus
> > makes the code more clear. E.g., the current construct_tdmr() can just
> > take the structure which contains "TDMR Info" metadata fields.
> >
> > Start with moving 'struct tdx_tdmr_sysinfo' to 'struct tdx_sysinfo', and
> > rename 'struct tdx_tdmr_sysinfo' to 'struct tdx_sysinfo_tdmr_info' to
> > make it consistent with the "class name".
> >
> > Add a new function get_tdx_sysinfo() as the place to read all metadata
> > fields, and call it at the beginning of init_tdx_module(). Move the
> > existing get_tdx_tdmr_sysinfo() to get_tdx_sysinfo().
> >
> > Note there is a functional change: get_tdx_tdmr_sysinfo() is moved from
> > after build_tdx_memlist() to before it, but it is fine to do so.
>
> Why? I don't see build_tdx_memlist() using any tdmr data.
This is a preparation patch to track more metadata fields in one 'struct
tdx_sysinfo'. Eventually (as mentioned in the changelog) there will be
more fields not related to TDX module initialization in that structure.
It makes more sense to read metadata first, and then the consumers can use
them.
You also observed that build_tdx_memlist() doesn't use any tdmr data, thus
the order doesn't matter from functionality's perspective.
Switching the order is part of "start to track all global metadata in one
structure".
>
> >
> > Signed-off-by: Kai Huang <kai.huang@intel.com>
>
> This patch semantically does 3 independent things :
>
> 1. Renames tdx_tdmr_sysinfo to tdx_sysinfo_tdmr_info
> 2. Introduces tdx_sysinfo and puts the aforementioned struct in it.
> 3. Moves get_tdx_tdmr_sysinfo
What's wrong of doing them together, as "start to track all global
metadata in one structure"?
>
> > ---
> > arch/x86/virt/vmx/tdx/tdx.c | 29 +++++++++++++++++------------
> > arch/x86/virt/vmx/tdx/tdx.h | 32 +++++++++++++++++++++++++-------
> > 2 files changed, 42 insertions(+), 19 deletions(-)
> >
> > diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> > index fad42014ca37..4683884efcc6 100644
> > --- a/arch/x86/virt/vmx/tdx/tdx.c
> > +++ b/arch/x86/virt/vmx/tdx/tdx.c
> > @@ -320,11 +320,11 @@ static int stbuf_read_sysmd_multi(const struct field_mapping *fields,
> > }
> >
> > #define TD_SYSINFO_MAP_TDMR_INFO(_field_id, _member) \
> > - TD_SYSINFO_MAP(_field_id, struct tdx_tdmr_sysinfo, _member)
> > + TD_SYSINFO_MAP(_field_id, struct tdx_sysinfo_tdmr_info, _member)
> >
> > -static int get_tdx_tdmr_sysinfo(struct tdx_tdmr_sysinfo *tdmr_sysinfo)
> > +static int get_tdx_tdmr_sysinfo(struct tdx_sysinfo_tdmr_info *tdmr_sysinfo)
> > {
> > - /* Map TD_SYSINFO fields into 'struct tdx_tdmr_sysinfo': */
> > + /* Map TD_SYSINFO fields into 'struct tdx_sysinfo_tdmr_info': */
> > static const struct field_mapping fields[] = {
> > TD_SYSINFO_MAP_TDMR_INFO(MAX_TDMRS, max_tdmrs),
> > TD_SYSINFO_MAP_TDMR_INFO(MAX_RESERVED_PER_TDMR, max_reserved_per_tdmr),
> > @@ -337,6 +337,11 @@ static int get_tdx_tdmr_sysinfo(struct tdx_tdmr_sysinfo *tdmr_sysinfo)
> > return stbuf_read_sysmd_multi(fields, ARRAY_SIZE(fields), tdmr_sysinfo);
> > }
> >
> > +static int get_tdx_sysinfo(struct tdx_sysinfo *sysinfo)
>
> What's the point of this function, directly calling
> get_tdx_tdmr_sysinfo(&sysinfo->tdmr_info); isn't any less obvious.
The patch title says "start to track all global metadata in one
structure". 'struct tdx_sysinf' is that structure.
>
> > +{
> > + return get_tdx_tdmr_sysinfo(&sysinfo->tdmr_info);
> > +}
> > +
> > /* Calculate the actual TDMR size */
> > static int tdmr_size_single(u16 max_reserved_per_tdmr)
> > {
>
> <snip>
next prev parent reply other threads:[~2024-06-18 23:54 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-16 12:01 [PATCH 0/9] TDX host: metadata reading tweaks, bug fix and info dump Kai Huang
2024-06-16 12:01 ` [PATCH 1/9] x86/virt/tdx: Rename _offset to _member for TD_SYSINFO_MAP() macro Kai Huang
2024-06-16 12:01 ` [PATCH 2/9] x86/virt/tdx: Unbind global metadata read with 'struct tdx_tdmr_sysinfo' Kai Huang
2024-06-18 11:23 ` Nikolay Borisov
2024-06-18 23:29 ` Huang, Kai
2024-06-16 12:01 ` [PATCH 3/9] x86/virt/tdx: Support global metadata read for all element sizes Kai Huang
2024-06-18 11:42 ` Nikolay Borisov
2024-06-18 23:28 ` Huang, Kai
2024-06-19 8:05 ` Nikolay Borisov
2024-06-19 9:51 ` Huang, Kai
2024-06-16 12:01 ` [PATCH 4/9] x86/virt/tdx: Abstract reading multiple global metadata fields as a helper Kai Huang
2024-06-18 11:45 ` Nikolay Borisov
2024-06-18 23:42 ` Huang, Kai
2024-06-16 12:01 ` [PATCH 5/9] x86/virt/tdx: Move field mapping table of getting TDMR info to function local Kai Huang
2024-06-18 11:47 ` Nikolay Borisov
2024-06-18 23:44 ` Huang, Kai
2024-06-16 12:01 ` [PATCH 6/9] x86/virt/tdx: Start to track all global metadata in one structure Kai Huang
2024-06-18 13:17 ` Nikolay Borisov
2024-06-18 23:54 ` Huang, Kai [this message]
2024-06-16 12:01 ` [PATCH 7/9] x86/virt/tdx: Print TDX module basic information Kai Huang
2024-06-18 13:52 ` Nikolay Borisov
2024-06-19 0:22 ` Huang, Kai
2024-06-16 12:01 ` [PATCH 8/9] x86/virt/tdx: Exclude memory region hole within CMR as TDMR's reserved area Kai Huang
2024-06-17 10:54 ` Chao Gao
2024-06-18 0:12 ` Huang, Kai
2024-06-18 15:10 ` Nikolay Borisov
2024-06-19 1:23 ` Huang, Kai
2024-06-19 4:58 ` Huang, Kai
2024-07-05 3:00 ` Binbin Wu
2024-07-05 9:36 ` Huang, Kai
2024-06-16 12:01 ` [PATCH 9/9] x86/virt/tdx: Don't initialize module that doesn't support NO_RBP_MOD feature Kai Huang
2024-06-18 15:12 ` Nikolay Borisov
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=ed0aee511389e7ce52b5b6d390d12ccbd346cfb4.camel@intel.com \
--to=kai.huang@intel.com \
--cc=binbin.wu@linux.intel.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.com \
--cc=isaku.yamahata@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nik.borisov@suse.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox