From: Dave Hansen <dave.hansen@intel.com>
To: Kai Huang <kai.huang@intel.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: seanjc@google.com, pbonzini@redhat.com, len.brown@intel.com,
tony.luck@intel.com, rafael.j.wysocki@intel.com,
reinette.chatre@intel.com, dan.j.williams@intel.com,
peterz@infradead.org, ak@linux.intel.com,
kirill.shutemov@linux.intel.com,
sathyanarayanan.kuppuswamy@linux.intel.com,
isaku.yamahata@intel.com
Subject: Re: [PATCH v3 04/21] x86/virt/tdx: Add skeleton for detecting and initializing TDX on demand
Date: Wed, 27 Apr 2022 07:49:50 -0700 [thread overview]
Message-ID: <c833aff2-b459-a1d7-431f-bce5c5f29182@intel.com> (raw)
In-Reply-To: <22e3adf42b8ea2cae3aabc26f762acb983133fea.camel@intel.com>
On 4/26/22 17:43, Kai Huang wrote:
> On Tue, 2022-04-26 at 13:53 -0700, Dave Hansen wrote:
>> On 4/5/22 21:49, Kai Huang wrote:
...
>>> +static bool tdx_keyid_sufficient(void)
>>> +{
>>> + if (!cpumask_equal(&cpus_booted_once_mask,
>>> + cpu_present_mask))
>>> + return false;
>>
>> I'd move this cpumask_equal() to a helper.
>
> Sorry to double confirm, do you want something like:
>
> static bool tdx_detected_on_all_cpus(void)
> {
> /*
> * To detect any BIOS misconfiguration among cores, all logical
> * cpus must have been brought up at least once. This is true
> * unless 'maxcpus' kernel command line is used to limit the
> * number of cpus to be brought up during boot time. However
> * 'maxcpus' is basically an invalid operation mode due to the
> * MCE broadcast problem, and it should not be used on a TDX
> * capable machine. Just do paranoid check here and do not
> * report SEAMRR as enabled in this case.
> */
> return cpumask_equal(&cpus_booted_once_mask, cpu_present_mask);
> }
That's logically the right idea, but I hate the name since the actual
test has nothing to do with TDX being detected. The comment is also
rather verbose and rambling.
It should be named something like:
all_cpus_booted()
and with a comment like this:
/*
* To initialize TDX, the kernel needs to run some code on every
* present CPU. Detect cases where present CPUs have not been
* booted, like when maxcpus=N is used.
*/
> static bool seamrr_enabled(void)
> {
> if (!tdx_detected_on_all_cpus())
> return false;
>
> return __seamrr_enabled();
> }
>
> static bool tdx_keyid_sufficient()
> {
> if (!tdx_detected_on_all_cpus())
> return false;
>
> ...
> }
Although, looking at those, it's *still* unclear why you need this. I
assume it's because some later TDX SEAMCALL will fail if you get this
wrong, and you want to be able to provide a better error message.
*BUT* this code doesn't actually provide halfway reasonable error
messages. If someone uses maxcpus=99, then this code will report:
pr_info("SEAMRR not enabled.\n");
right? That's bonkers.
>>> + /*
>>> + * TDX requires at least two KeyIDs: one global KeyID to
>>> + * protect the metadata of the TDX module and one or more
>>> + * KeyIDs to run TD guests.
>>> + */
>>> + return tdx_keyid_num >= 2;
>>> +}
>>> +
>>> +static int __tdx_detect(void)
>>> +{
>>> + /* The TDX module is not loaded if SEAMRR is disabled */
>>> + if (!seamrr_enabled()) {
>>> + pr_info("SEAMRR not enabled.\n");
>>> + goto no_tdx_module;
>>> + }
>>
>> Why even bother with the SEAMRR stuff? It sounded like you can "ping"
>> the module with SEAMCALL. Why not just use that directly?
>
> SEAMCALL will cause #GP if SEAMRR is not enabled. We should check whether
> SEAMRR is enabled before making SEAMCALL.
So... You could actually get rid of all this code. if SEAMCALL #GP's,
then you say, "Whoops, the firmware didn't load the TDX module
correctly, sorry."
Why is all this code here? What is it for?
>>> + /*
>>> + * Also do not report the TDX module as loaded if there's
>>> + * no enough TDX private KeyIDs to run any TD guests.
>>> + */
>>> + if (!tdx_keyid_sufficient()) {
>>> + pr_info("Number of TDX private KeyIDs too small: %u.\n",
>>> + tdx_keyid_num);
>>> + goto no_tdx_module;
>>> + }
>>> +
>>> + /* Return -ENODEV until the TDX module is detected */
>>> +no_tdx_module:
>>> + tdx_module_status = TDX_MODULE_NONE;
>>> + return -ENODEV;
>>> +}
Again, if someone uses maxcpus=1234 and we get down here, then it
reports to the user:
Number of TDX private KeyIDs too small: ...
???? When the root of the problem has nothing to do with KeyIDs.
>>> +static int init_tdx_module(void)
>>> +{
>>> + /*
>>> + * Return -EFAULT until all steps of TDX module
>>> + * initialization are done.
>>> + */
>>> + return -EFAULT;
>>> +}
>>> +
>>> +static void shutdown_tdx_module(void)
>>> +{
>>> + /* TODO: Shut down the TDX module */
>>> + tdx_module_status = TDX_MODULE_SHUTDOWN;
>>> +}
>>> +
>>> +static int __tdx_init(void)
>>> +{
>>> + int ret;
>>> +
>>> + /*
>>> + * Logical-cpu scope initialization requires calling one SEAMCALL
>>> + * on all logical cpus enabled by BIOS. Shutting down the TDX
>>> + * module also has such requirement. Further more, configuring
>>> + * the key of the global KeyID requires calling one SEAMCALL for
>>> + * each package. For simplicity, disable CPU hotplug in the whole
>>> + * initialization process.
>>> + *
>>> + * It's perhaps better to check whether all BIOS-enabled cpus are
>>> + * online before starting initializing, and return early if not.
>>
>> But you did some of this cpumask checking above. Right?
>
> Above check only guarantees SEAMRR/TDX KeyID has been detected on all presnet
> cpus. the 'present' cpumask doesn't equal to all BIOS-enabled CPUs.
I have no idea what this is saying. In general, I have no idea what the
comment is saying. It makes zero sense. The locking pattern for stuff
like this is:
cpus_read_lock();
for_each_online_cpu()
do_something();
cpus_read_unlock();
because you need to make sure that you don't miss "do_something()" on a
CPU that comes online during the loop.
But, now that I think about it, all of the checks I've seen so far are
for *booted* CPUs. While the lock (I assume) would keep new CPUs from
booting, it doesn't do any good really since the "cpus_booted_once_mask"
bits are only set and not cleared. A CPU doesn't un-become booted once.
Again, we seem to have a long, verbose comment that says very little and
only confuses me.
...
>> Why does this need both a tdx_detect() and a tdx_init()? Shouldn't the
>> interface from outside just be "get TDX up and running, please?"
>
> We can have a single tdx_init(). However tdx_init() can be heavy, and having a
> separate non-heavy tdx_detect() may be useful if caller wants to separate
> "detecting the TDX module" and "initializing the TDX module", i.e. to do
> something in the middle.
<Sigh> So, this "design" went unmentioned, *and* I can't review if the
actual callers of this need the functionality or not because they're not
in this series.
> However tdx_detect() basically only detects P-SEAMLDR. If we move P-SEAMLDR
> detection to tdx_init(), or we git rid of P-SEAMLDR completely, then we don't
> need tdx_detect() anymore. We can expose seamrr_enabled() and TDX KeyID
> variables or functions so caller can use them to see whether it should do TDX
> related staff and then call tdx_init().
I don't think you've made a strong case for why P-SEAMLDR detection is
even necessary in this series.
next prev parent reply other threads:[~2022-04-27 14:46 UTC|newest]
Thread overview: 156+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-06 4:49 [PATCH v3 00/21] TDX host kernel support Kai Huang
2022-04-06 4:49 ` [PATCH v3 01/21] x86/virt/tdx: Detect SEAM Kai Huang
2022-04-18 22:29 ` Sathyanarayanan Kuppuswamy
2022-04-18 22:50 ` Sean Christopherson
2022-04-19 3:38 ` Kai Huang
2022-04-26 20:21 ` Dave Hansen
2022-04-26 23:12 ` Kai Huang
2022-04-26 23:28 ` Dave Hansen
2022-04-26 23:49 ` Kai Huang
2022-04-27 0:22 ` Sean Christopherson
2022-04-27 0:44 ` Kai Huang
2022-04-27 14:22 ` Dave Hansen
2022-04-27 22:39 ` Kai Huang
2022-04-06 4:49 ` [PATCH v3 02/21] x86/virt/tdx: Detect TDX private KeyIDs Kai Huang
2022-04-19 5:39 ` Sathyanarayanan Kuppuswamy
2022-04-19 9:41 ` Kai Huang
2022-04-19 5:42 ` Sathyanarayanan Kuppuswamy
2022-04-19 10:07 ` Kai Huang
2022-04-06 4:49 ` [PATCH v3 03/21] x86/virt/tdx: Implement the SEAMCALL base function Kai Huang
2022-04-19 14:07 ` Sathyanarayanan Kuppuswamy
2022-04-20 4:16 ` Kai Huang
2022-04-20 7:29 ` Sathyanarayanan Kuppuswamy
2022-04-20 10:39 ` Kai Huang
2022-04-26 20:37 ` Dave Hansen
2022-04-26 23:29 ` Kai Huang
2022-04-06 4:49 ` [PATCH v3 04/21] x86/virt/tdx: Add skeleton for detecting and initializing TDX on demand Kai Huang
2022-04-19 14:53 ` Sathyanarayanan Kuppuswamy
2022-04-20 4:37 ` Kai Huang
2022-04-20 5:21 ` Dave Hansen
2022-04-20 14:30 ` Sathyanarayanan Kuppuswamy
2022-04-20 22:35 ` Kai Huang
2022-04-26 20:53 ` Dave Hansen
2022-04-27 0:43 ` Kai Huang
2022-04-27 14:49 ` Dave Hansen [this message]
2022-04-28 0:00 ` Kai Huang
2022-04-28 14:27 ` Dave Hansen
2022-04-28 23:44 ` Kai Huang
2022-04-28 23:53 ` Dave Hansen
2022-04-29 0:11 ` Kai Huang
2022-04-29 0:26 ` Dave Hansen
2022-04-29 0:59 ` Kai Huang
2022-04-06 4:49 ` [PATCH v3 05/21] x86/virt/tdx: Detect P-SEAMLDR and TDX module Kai Huang
2022-04-26 20:56 ` Dave Hansen
2022-04-27 0:01 ` Kai Huang
2022-04-27 14:24 ` Dave Hansen
2022-04-27 21:30 ` Kai Huang
2022-04-06 4:49 ` [PATCH v3 06/21] x86/virt/tdx: Shut down TDX module in case of error Kai Huang
2022-04-23 15:39 ` Sathyanarayanan Kuppuswamy
2022-04-25 23:41 ` Kai Huang
2022-04-26 1:48 ` Sathyanarayanan Kuppuswamy
2022-04-26 2:12 ` Kai Huang
2022-04-26 20:59 ` Dave Hansen
2022-04-27 0:06 ` Kai Huang
2022-05-18 16:19 ` Sagi Shahar
2022-05-18 23:51 ` Kai Huang
2022-04-06 4:49 ` [PATCH v3 07/21] x86/virt/tdx: Do TDX module global initialization Kai Huang
2022-04-20 22:27 ` Sathyanarayanan Kuppuswamy
2022-04-20 22:37 ` Kai Huang
2022-04-06 4:49 ` [PATCH v3 08/21] x86/virt/tdx: Do logical-cpu scope TDX module initialization Kai Huang
2022-04-24 1:27 ` Sathyanarayanan Kuppuswamy
2022-04-25 23:55 ` Kai Huang
2022-04-06 4:49 ` [PATCH v3 09/21] x86/virt/tdx: Get information about TDX module and convertible memory Kai Huang
2022-04-25 2:58 ` Sathyanarayanan Kuppuswamy
2022-04-26 0:05 ` Kai Huang
2022-04-27 22:15 ` Dave Hansen
2022-04-28 0:15 ` Kai Huang
2022-04-28 14:06 ` Dave Hansen
2022-04-28 23:14 ` Kai Huang
2022-04-29 17:47 ` Dave Hansen
2022-05-02 5:04 ` Kai Huang
2022-05-25 4:47 ` Kai Huang
2022-05-25 4:57 ` Kai Huang
2022-05-25 16:00 ` Kai Huang
2022-05-18 22:30 ` Sagi Shahar
2022-05-18 23:56 ` Kai Huang
2022-04-06 4:49 ` [PATCH v3 10/21] x86/virt/tdx: Add placeholder to coveret all system RAM as TDX memory Kai Huang
2022-04-20 20:48 ` Isaku Yamahata
2022-04-20 22:38 ` Kai Huang
2022-04-27 22:24 ` Dave Hansen
2022-04-28 0:53 ` Kai Huang
2022-04-28 1:07 ` Dave Hansen
2022-04-28 1:35 ` Kai Huang
2022-04-28 3:40 ` Dave Hansen
2022-04-28 3:55 ` Kai Huang
2022-04-06 4:49 ` [PATCH v3 11/21] x86/virt/tdx: Choose to use " Kai Huang
2022-04-20 20:55 ` Isaku Yamahata
2022-04-20 22:39 ` Kai Huang
2022-04-28 15:54 ` Dave Hansen
2022-04-29 7:32 ` Kai Huang
2022-04-06 4:49 ` [PATCH v3 12/21] x86/virt/tdx: Create TDMRs to cover all system RAM Kai Huang
2022-04-28 16:22 ` Dave Hansen
2022-04-29 7:24 ` Kai Huang
2022-04-29 13:52 ` Dave Hansen
2022-04-06 4:49 ` [PATCH v3 13/21] x86/virt/tdx: Allocate and set up PAMTs for TDMRs Kai Huang
2022-04-28 17:12 ` Dave Hansen
2022-04-29 7:46 ` Kai Huang
2022-04-29 14:20 ` Dave Hansen
2022-04-29 14:30 ` Sean Christopherson
2022-04-29 17:46 ` Dave Hansen
2022-04-29 18:19 ` Sean Christopherson
2022-04-29 18:32 ` Dave Hansen
2022-05-02 5:59 ` Kai Huang
2022-05-02 14:17 ` Dave Hansen
2022-05-02 21:55 ` Kai Huang
2022-04-06 4:49 ` [PATCH v3 14/21] x86/virt/tdx: Set up reserved areas for all TDMRs Kai Huang
2022-04-06 4:49 ` [PATCH v3 15/21] x86/virt/tdx: Reserve TDX module global KeyID Kai Huang
2022-04-06 4:49 ` [PATCH v3 16/21] x86/virt/tdx: Configure TDX module with TDMRs and " Kai Huang
2022-04-06 4:49 ` [PATCH v3 17/21] x86/virt/tdx: Configure global KeyID on all packages Kai Huang
2022-04-06 4:49 ` [PATCH v3 18/21] x86/virt/tdx: Initialize all TDMRs Kai Huang
2022-04-06 4:49 ` [PATCH v3 19/21] x86: Flush cache of TDX private memory during kexec() Kai Huang
2022-04-06 4:49 ` [PATCH v3 20/21] x86/virt/tdx: Add kernel command line to opt-in TDX host support Kai Huang
2022-04-28 17:25 ` Dave Hansen
2022-04-06 4:49 ` [PATCH v3 21/21] Documentation/x86: Add documentation for " Kai Huang
2022-04-14 10:19 ` [PATCH v3 00/21] TDX host kernel support Kai Huang
2022-04-26 20:13 ` Dave Hansen
2022-04-27 1:15 ` Kai Huang
2022-04-27 21:59 ` Dave Hansen
2022-04-28 0:37 ` Kai Huang
2022-04-28 0:50 ` Dave Hansen
2022-04-28 0:58 ` Kai Huang
2022-04-29 1:40 ` Kai Huang
2022-04-29 3:04 ` Dan Williams
2022-04-29 5:35 ` Kai Huang
2022-05-03 23:59 ` Kai Huang
2022-05-04 0:25 ` Dave Hansen
2022-05-04 1:15 ` Kai Huang
2022-05-05 9:54 ` Kai Huang
2022-05-05 13:51 ` Dan Williams
2022-05-05 22:14 ` Kai Huang
2022-05-06 0:22 ` Dan Williams
2022-05-06 0:45 ` Kai Huang
2022-05-06 1:15 ` Dan Williams
2022-05-06 1:46 ` Kai Huang
2022-05-06 15:57 ` Dan Williams
2022-05-09 2:46 ` Kai Huang
2022-05-10 10:25 ` Kai Huang
2022-05-07 0:09 ` Mike Rapoport
2022-05-08 10:00 ` Kai Huang
2022-05-09 10:33 ` Mike Rapoport
2022-05-09 23:27 ` Kai Huang
2022-05-04 14:31 ` Dan Williams
2022-05-04 22:50 ` Kai Huang
2022-04-28 1:01 ` Dan Williams
2022-04-28 1:21 ` Kai Huang
2022-04-29 2:58 ` Dan Williams
2022-04-29 5:43 ` Kai Huang
2022-04-29 14:39 ` Dave Hansen
2022-04-29 15:18 ` Dan Williams
2022-04-29 17:18 ` Dave Hansen
2022-04-29 17:48 ` Dan Williams
2022-04-29 18:34 ` Dave Hansen
2022-04-29 18:47 ` Dan Williams
2022-04-29 19:20 ` Dave Hansen
2022-04-29 21:20 ` Dan Williams
2022-04-29 21:27 ` Dave Hansen
2022-05-02 10:18 ` Kai Huang
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=c833aff2-b459-a1d7-431f-bce5c5f29182@intel.com \
--to=dave.hansen@intel.com \
--cc=ak@linux.intel.com \
--cc=dan.j.williams@intel.com \
--cc=isaku.yamahata@intel.com \
--cc=kai.huang@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=reinette.chatre@intel.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=tony.luck@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome