[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6720042edf637_bc69d29491@dwillia2-xfh.jf.intel.com.notmuch>
Date: Mon, 28 Oct 2024 14:37:50 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Kai Huang <kai.huang@...el.com>, <dave.hansen@...el.com>,
<kirill.shutemov@...ux.intel.com>, <tglx@...utronix.de>, <bp@...en8.de>,
<peterz@...radead.org>, <mingo@...hat.com>, <hpa@...or.com>,
<dan.j.williams@...el.com>, <seanjc@...gle.com>, <pbonzini@...hat.com>
CC: <x86@...nel.org>, <linux-kernel@...r.kernel.org>, <kvm@...r.kernel.org>,
<rick.p.edgecombe@...el.com>, <isaku.yamahata@...el.com>,
<adrian.hunter@...el.com>, <nik.borisov@...e.com>, <kai.huang@...el.com>
Subject: Re: [PATCH v6 02/10] x86/virt/tdx: Start to track all global
metadata in one structure
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_sys_info' to track all
> global metadata fields.
>
> TDX categories global metadata fields into different "Classes". E.g.,
> the TDMR related fields are under class "TDMR Info". Instead of making
> 'struct tdx_sys_info' 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 construct_tdmr() can just take the
> structure which contains "TDMR Info" metadata fields.
>
> Add a new function get_tdx_sys_info() as the placeholder to read all
> metadata fields, and call it at the beginning of init_tdx_module(). For
> now it only calls get_tdx_sys_info_tdmr() to read TDMR related fields.
>
> Note there is a functional change: get_tdx_sys_info_tdmr() is moved from
> after build_tdx_memlist() to before it, but it is fine to do so.
>
> Signed-off-by: Kai Huang <kai.huang@...el.com>
> Reviewed-by: Adrian Hunter <adrian.hunter@...el.com>
Looks good to me:
Reviewed-by: Dan Williams <dan.j.williams@...el.com>
Powered by blists - more mailing lists