linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kai Huang <kai.huang@intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Gleixner, Thomas" <thomas.gleixner@intel.com>
Cc: "Hansen, Dave" <dave.hansen@intel.com>, "Christopherson,,
	Sean" <seanjc@google.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"kirill.shutemov@linux.intel.com"
	<kirill.shutemov@linux.intel.com>,
	"sathyanarayanan.kuppuswamy@linux.intel.com" 
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"Luck, Tony" <tony.luck@intel.com>,
	"ak@linux.intel.com" <ak@linux.intel.com>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"Yamahata, Isaku" <isaku.yamahata@intel.com>
Subject: Re: [PATCH v2 04/21] x86/virt/tdx: Add skeleton for detecting and initializing TDX on demand
Date: Tue, 29 Mar 2022 11:55:01 +1300	[thread overview]
Message-ID: <8f85e6ad76508e0b7ac8667b1c0b7b3b43d67ef8.camel@intel.com> (raw)
In-Reply-To: <BN9PR11MB52761E8DE55DC8872EC093758C1D9@BN9PR11MB5276.namprd11.prod.outlook.com>

On Tue, 2022-03-29 at 00:47 +1300, Tian, Kevin wrote:
> > From: Huang, Kai <kai.huang@intel.com>
> > Sent: Monday, March 28, 2022 5:24 PM
> > > 
> > > cpu_present_mask does not always represent BIOS-enabled CPUs due
> > > to those boot options. Then why do we care whether CPUs in this mask
> > > (if only representing a subset of BIOS-enabled CPUs) are at least brought
> > > up once? It will fail at TDH.SYS.CONFIG anyway.
> > 
> > As I said, this is used to make sure SEAMRR has been detected on all cpus,
> > so
> > that any BIOS misconfiguration on SEAMRR has been detected.  Otherwise,
> > seamrr_enabled() may not be reliable (theoretically).
> 
> *all cpus* is questionable.
> 
> Say BIOS enabled 8 CPUs: [0 - 7]
> 
> cpu_present_map covers [0 - 5], due to nr_cpus=6
> 
> You compared cpus_booted_once_mask to cpu_present_mask so if maxcpus
> is set to a number < nr_cpus SEAMRR is considered disabled because you
> cannot verify CPUs between [max_cpus, nr_cpus). 

SEAMRR is not considered as disabled in this case, at least in my intention.  My
understanding on the spec is if SEAMRR is configured as enabled on one core (the
SEAMRR MSRs are core-scope), the SEAMCALL instruction can work on that core.  It
is TDX's requirement that some SEAMCALL needs to be done on all BIOS-enabled
CPUs to finish TDX initialization, but not SEAM's.

From this perspective, if we forget TDX at this moment but talk about SEAM
alone, it might make sense to not just treat SEAMRR as disabled if kernel usable
cpus are limited by 'nr_cpus'.  The chance that BIOS misconfigured SEAMRR is
really rare.  If kernel can detect potential BIOS misconfiguration, it should do
it.  Otherwise, perhaps it's more reasonable not to just treat SEAM as disabled.


> If following the same
> rationale then you also need a proper way to detect the case where nr_cpus
> < BIOS enabled number i.e. when you cannot verify SEAMRR on CPUs
> between [nr_cpus, 7]. otherwise this check is just incomplete.
> 
> But the entire check is actually unnecessary. You just need to verify SEAMRR
> and do TDX cpu init on online CPUs. Any gap between online ones and BIOS
> enabled ones will be caught by the TDX module at TDH.SYS.CONFIG point.

This is equivalent to not having the paranoid check in seamrr_enabled(). By
detecting SEAMRR in identify_cpu(), the detection has already been done for any
online cpu.

> 
> > 
> > Alternatively, I think we can also add check to disable TDX when 'maxcpus'
> > has
> > been specified, but I think the current way is better.
> > 
> > > 
> > > btw your comment said that 'maxcpus' is basically an invalid mode
> > > due to MCE broadcase problem. I didn't find any code to block it when
> > > MCE is enabled,
> > 
> > Please see below comment in cpu_smt_allowed():
> > 
> > static inline bool cpu_smt_allowed(unsigned int cpu)
> > {
> >       ...
> >         /*
> >          * On x86 it's required to boot all logical CPUs at least once so
> >          * that the init code can get a chance to set CR4.MCE on each
> >          * CPU. Otherwise, a broadcasted MCE observing CR4.MCE=0b on any
> >          * core will shutdown the machine.
> >          */
> >        return !cpumask_test_cpu(cpu, &cpus_booted_once_mask);
> > }
> 
> I saw that code. My point is more about your statement that maxcpus
> is almost invalid due to above situation then why didn't we do anything
> to document such restriction or throw out a warning when it's
> misconfigured...

The sentence "'maxcpus' is an invalid operation mode due to the MCE broadcast
problem" was from Thomas.  Perhaps I should not just put it into the comment.

Also, Thomas suggested:

"you should have a paranoia check which checks for the maxcpus
command line parameter and if it's there and smaller than the number of
present CPUs then you just refuse to enable TDX.

Alternatively you just have a separate cpumask tdx_availabe_mask and
keep track of the CPUs which have been checked. When TDX is initialized
you then can do:

    if (!cpumask_equal(cpu_present_mask, tdx_available_mask))
    	     return;
"

I found we can just use cpus_booted_once_mask, instead of tdx_available_mask, so
I used the second way.  And instead of putting the check when initializing TDX,
I put to seamrr_enabled() since I guess it's more reasonable to be here as the
logic is to make sure SEAMRR has been detected on all cpus.

Hi Thomas,

If you see this, sorry for quoting your words here.  Just want to have a better
discussion.  And appreciate if you can have some guidance here.

> 
> > 
> > > thus wonder the rationale behind and whether that
> > > rationale can be brought to this series (i.e. no check against those
> > > conflicting boot options and just let SEAMCALL itself to detect and fail).
> > > 
> > > @Thomas, any guidance here?
> > > 
> > > Thanks
> > > Kevin
> 


  reply	other threads:[~2022-03-28 22:55 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-13 10:49 [PATCH v2 00/21] TDX host kernel support Kai Huang
2022-03-13 10:49 ` [PATCH v2 01/21] x86/virt/tdx: Detect SEAM Kai Huang
2022-03-23  3:21   ` Tian, Kevin
2022-03-28  3:55     ` Kai Huang
2022-03-28  8:10       ` Tian, Kevin
2022-03-29 17:52         ` Isaku Yamahata
2022-03-29 23:28           ` Kai Huang
2022-03-13 10:49 ` [PATCH v2 02/21] x86/virt/tdx: Detect TDX private KeyIDs Kai Huang
2022-03-13 10:49 ` [PATCH v2 03/21] x86/virt/tdx: Implement the SEAMCALL base function Kai Huang
2022-03-23  3:35   ` Tian, Kevin
2022-03-28  1:41     ` Kai Huang
2022-03-28  8:16       ` Tian, Kevin
2022-03-28  9:10         ` Kai Huang
2022-03-13 10:49 ` [PATCH v2 04/21] x86/virt/tdx: Add skeleton for detecting and initializing TDX on demand Kai Huang
2022-03-23  6:49   ` Tian, Kevin
2022-03-28  1:57     ` Kai Huang
2022-03-28  8:26       ` Tian, Kevin
2022-03-28  9:24         ` Kai Huang
2022-03-28 11:47           ` Tian, Kevin
2022-03-28 22:55             ` Kai Huang [this message]
2022-03-29  2:36               ` Tian, Kevin
2022-03-29  3:10                 ` Kai Huang
2022-03-29  3:17                   ` Kai Huang
2022-03-13 10:49 ` [PATCH v2 05/21] x86/virt/tdx: Detect P-SEAMLDR and TDX module Kai Huang
2022-03-13 10:49 ` [PATCH v2 06/21] x86/virt/tdx: Shut down TDX module in case of error Kai Huang
2022-03-13 10:49 ` [PATCH v2 07/21] x86/virt/tdx: Do TDX module global initialization Kai Huang
2022-03-13 10:49 ` [PATCH v2 08/21] x86/virt/tdx: Do logical-cpu scope TDX module initialization Kai Huang
2022-03-13 10:49 ` [PATCH v2 09/21] x86/virt/tdx: Get information about TDX module and convertible memory Kai Huang
2022-03-24 17:43   ` Isaku Yamahata
2022-03-28  1:30     ` Kai Huang
2022-03-28 20:22       ` Isaku Yamahata
2022-03-28 20:30         ` Dave Hansen
2022-03-28 23:40           ` Kai Huang
2022-03-28 23:44             ` Dave Hansen
2022-03-29  0:04               ` Kai Huang
2022-03-13 10:49 ` [PATCH v2 10/21] x86/virt/tdx: Add placeholder to coveret all system RAM as TDX memory Kai Huang
2022-03-13 10:49 ` [PATCH v2 11/21] x86/virt/tdx: Choose to use " Kai Huang
2022-03-13 10:49 ` [PATCH v2 12/21] x86/virt/tdx: Create TDMRs to cover all system RAM Kai Huang
2022-03-13 10:49 ` [PATCH v2 13/21] x86/virt/tdx: Allocate and set up PAMTs for TDMRs Kai Huang
2022-03-24 18:06   ` Isaku Yamahata
2022-03-28  1:16     ` Kai Huang
2022-03-13 10:49 ` [PATCH v2 14/21] x86/virt/tdx: Set up reserved areas for all TDMRs Kai Huang
2022-03-13 10:49 ` [PATCH v2 15/21] x86/virt/tdx: Reserve TDX module global KeyID Kai Huang
2022-03-13 10:49 ` [PATCH v2 16/21] x86/virt/tdx: Configure TDX module with TDMRs and " Kai Huang
2022-03-13 10:49 ` [PATCH v2 17/21] x86/virt/tdx: Configure global KeyID on all packages Kai Huang
2022-03-24 18:18   ` isaku.yamahata
2022-03-28  1:19     ` Kai Huang
2022-03-13 10:49 ` [PATCH v2 18/21] x86/virt/tdx: Initialize all TDMRs Kai Huang
2022-03-13 10:49 ` [PATCH v2 19/21] x86: Flush cache of TDX private memory during kexec() Kai Huang
2022-03-13 10:50 ` [PATCH v2 20/21] x86/virt/tdx: Add kernel command line to opt-in TDX host support Kai Huang
2022-03-13 10:50 ` [PATCH v2 21/21] Documentation/x86: Add documentation for " 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=8f85e6ad76508e0b7ac8667b1c0b7b3b43d67ef8.camel@intel.com \
    --to=kai.huang@intel.com \
    --cc=ak@linux.intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=isaku.yamahata@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=seanjc@google.com \
    --cc=thomas.gleixner@intel.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;
as well as URLs for NNTP newsgroup(s).