From: "Huang, Kai" <kai.huang@intel.com>
To: "Hansen, Dave" <dave.hansen@intel.com>,
"seanjc@google.com" <seanjc@google.com>,
"bp@alien8.de" <bp@alien8.de>,
"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>
Cc: "Gao, Chao" <chao.gao@intel.com>,
"Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Hunter, Adrian" <adrian.hunter@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"Yamahata, Isaku" <isaku.yamahata@intel.com>
Subject: Re: [PATCH v3 7/8] x86/virt/tdx: Reduce TDMR's reserved areas by using CMRs to find memory holes
Date: Mon, 9 Sep 2024 10:30:17 +0000 [thread overview]
Message-ID: <12022e5dc5fc8f1ecf889a8700cc0031d5f04e0f.camel@intel.com> (raw)
In-Reply-To: <66db90d269408_22a22948c@dwillia2-xfh.jf.intel.com.notmuch>
On Fri, 2024-09-06 at 16:31 -0700, Dan Williams wrote:
> Kai Huang wrote:
> > A TDX module initialization failure was reported on a Emerald Rapids
> > platform:
> >
> > virt/tdx: initialization failed: TDMR [0x0, 0x80000000): reserved areas exhausted.
> > virt/tdx: module initialization failed (-28)
> >
> [..]
>
> I feel what I trimmed above is a lot of text just to say:
>
> "build_tdx_memlist() tries to fulfill the TDX module requirement it be
> told about holes in the TDMR space <insert pointer / reference to
> requirement>. It turns out that the kernel's view of memory holes is too
> fine grained and sometimes exceeds the number of holes (16) that the TDX
> module can track per TDMR <insert problematic memory map>. Thankfully
> the module also lists memory that is potentially convertible in a list
> of CMRs. That coarser grained CMR list tends to track usable memory in
> the memory map even if it might be reserved for host usage like 'ACPI
> data'. Use that list to relax what the kernel considers unusable
> memory. If it falls in a CMR no need to instantiate a hole, and rely on
> the fact that kernel will keep what it considers 'reserved' out of the
> page allocator."
>
> ...but don't spin the patch just to make the changelog more concise. It
> took me reading a few times to pull out those salient details, that is,
> if I understood it correctly?
Thanks. Let me try to trim down the changelog since I need to send out another
version anyway.
>
> > diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> > index 0fb673dd43ed..fa335ab1ae92 100644
> > --- a/arch/x86/virt/vmx/tdx/tdx.c
> > +++ b/arch/x86/virt/vmx/tdx/tdx.c
> > @@ -331,6 +331,72 @@ static int get_tdx_sys_info_version(struct tdx_sys_info_version *sysinfo_version
> > return ret;
> > }
> >
> > +/* Update the @sysinfo_cmr->num_cmrs to trim tail empty CMRs */
> > +static void trim_empty_tail_cmrs(struct tdx_sys_info_cmr *sysinfo_cmr)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < sysinfo_cmr->num_cmrs; i++) {
> > + u64 cmr_base = sysinfo_cmr->cmr_base[i];
> > + u64 cmr_size = sysinfo_cmr->cmr_size[i];
> > +
> > + if (!cmr_size) {
> > + WARN_ON_ONCE(cmr_base);
> > + break;
> > + }
> > +
> > + /* TDX architecture: CMR must be 4KB aligned */
> > + WARN_ON_ONCE(!PAGE_ALIGNED(cmr_base) ||
> > + !PAGE_ALIGNED(cmr_size));
>
> Is it really required to let the TDX module taint and possibly crash the
> kernel if it provides misaligned CMRs? Shouldn't these be validated
> early and just turn off TDX support if the TDX module is this broken?
We can make this function return error code for those error cases, and fail to
initialize TDX module.
But CMRs are actually verified by the MCHECK. If any WARN() above happens, TDX
won't get enabled in hardware. I think maybe we can just remove the WARN()s?
next prev parent reply other threads:[~2024-09-09 10:30 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-27 7:14 [PATCH v3 0/8] TDX host: metadata reading tweaks, bug fix and info dump Kai Huang
2024-08-27 7:14 ` [PATCH v3 1/8] x86/virt/tdx: Rename 'struct tdx_tdmr_sysinfo' to reflect the spec better Kai Huang
2024-08-27 13:10 ` Adrian Hunter
2024-08-27 22:20 ` Huang, Kai
2024-09-24 11:39 ` Huang, Kai
2024-08-30 22:05 ` Dan Williams
2024-08-27 7:14 ` [PATCH v3 2/8] x86/virt/tdx: Remove 'struct field_mapping' and implement TD_SYSINFO_MAP() macro Kai Huang
2024-08-29 7:20 ` Adrian Hunter
2024-08-30 10:52 ` Huang, Kai
2024-09-06 21:30 ` Dan Williams
2024-09-09 9:59 ` Huang, Kai
2024-09-06 20:21 ` Dan Williams
2024-09-09 9:59 ` Huang, Kai
2024-08-27 7:14 ` [PATCH v3 3/8] x86/virt/tdx: Prepare to support reading other global metadata fields Kai Huang
2024-08-30 6:43 ` Adrian Hunter
2024-08-30 11:02 ` Huang, Kai
2024-08-30 9:05 ` Nikolay Borisov
2024-08-30 11:09 ` Huang, Kai
2024-09-06 21:34 ` Dan Williams
2024-09-09 12:28 ` Huang, Kai
2024-08-27 7:14 ` [PATCH v3 4/8] x86/virt/tdx: Refine a comment to reflect the latest TDX spec Kai Huang
2024-08-30 6:45 ` Adrian Hunter
2024-08-30 9:14 ` Nikolay Borisov
2024-08-27 7:14 ` [PATCH v3 5/8] x86/virt/tdx: Start to track all global metadata in one structure Kai Huang
2024-08-30 7:02 ` Adrian Hunter
2024-08-30 11:10 ` Huang, Kai
2024-08-30 11:01 ` Nikolay Borisov
2024-08-30 11:57 ` Huang, Kai
2024-08-27 7:14 ` [PATCH v3 6/8] x86/virt/tdx: Print TDX module basic information Kai Huang
2024-09-06 22:46 ` Dan Williams
2024-09-09 10:18 ` Huang, Kai
2024-08-27 7:14 ` [PATCH v3 7/8] x86/virt/tdx: Reduce TDMR's reserved areas by using CMRs to find memory holes Kai Huang
2024-08-30 10:50 ` Adrian Hunter
2024-08-30 11:52 ` Huang, Kai
2024-08-30 12:02 ` Adrian Hunter
2024-08-30 12:27 ` Nikolay Borisov
2024-09-06 23:31 ` Dan Williams
2024-09-09 10:30 ` Huang, Kai [this message]
2024-08-27 7:14 ` [PATCH v3 8/8] x86/virt/tdx: Don't initialize module that doesn't support NO_RBP_MOD feature Kai Huang
2024-08-30 11:01 ` Adrian Hunter
2024-09-06 23:36 ` Dan Williams
2024-09-09 10:21 ` Huang, Kai
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=12022e5dc5fc8f1ecf889a8700cc0031d5f04e0f.camel@intel.com \
--to=kai.huang@intel.com \
--cc=adrian.hunter@intel.com \
--cc=binbin.wu@linux.intel.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--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=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
all inboxes | Powered by JetHome®