All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huang, Kai" <kai.huang@intel.com>
To: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"david@redhat.com" <david@redhat.com>,
	"bagasdotme@gmail.com" <bagasdotme@gmail.com>,
	"ak@linux.intel.com" <ak@linux.intel.com>,
	"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
	"kirill.shutemov@linux.intel.com"
	<kirill.shutemov@linux.intel.com>, "Christopherson,,
	Sean" <seanjc@google.com>,
	"Chatre, Reinette" <reinette.chatre@intel.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"Yamahata, Isaku" <isaku.yamahata@intel.com>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"Shahar, Sagi" <sagis@google.com>,
	"imammedo@redhat.com" <imammedo@redhat.com>,
	"Gao, Chao" <chao.gao@intel.com>,
	"Brown, Len" <len.brown@intel.com>,
	"sathyanarayanan.kuppuswamy@linux.intel.com" 
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	"Huang, Ying" <ying.huang@intel.com>,
	"Williams, Dan J" <dan.j.williams@intel.com>
Subject: Re: [PATCH v9 07/18] x86/virt/tdx: Do TDX module per-cpu initialization
Date: Mon, 13 Feb 2023 23:43:42 +0000	[thread overview]
Message-ID: <8e9238bbcccedfa00e2dbec87e1d77d370911846.camel@intel.com> (raw)
In-Reply-To: <2d7141b1-1d76-4e67-60d2-471a524c372e@intel.com>

On Mon, 2023-02-13 at 14:28 -0800, Dave Hansen wrote:
> On 2/13/23 13:13, Huang, Kai wrote:
> > Perhaps I didn't explain clearly in the comment.  Below is the updated one:
> > 
> >                 /*
> >                  * The previous call of __tdx_enable() may only have
> >                  * initialized part of present cpus during module
> >                  * initialization, and new cpus may have become online
> >                  * since then w/o doing per-cpu initialization.
> >                  *
> >                  * For example, a new CPU can become online when KVM is
> >                  * unloaded, in which case tdx_cpu_enable() is not called since
> >                  * KVM's CPU online callback has been removed.
> >                  *
> >                  * To make sure all online cpus are TDX-runnable, always
> >                  * do per-cpu initialization for all online cpus here
> >                  * even the module has been initialized.
> >                  */
> 
> This is voodoo.
> 
> I want a TDX-specific hotplug CPU handler.  Period.  Please make that
> happen.  
> 

Yes 100% agreed.

> Put that code in this patch.  That handler should:
> 
> 	1. Run after the KVM handler (if present)
> 	2. See if VMX is on
> 	3. If VMX is on:
> 	 3a. Run smp_func_module_lp_init(), else
> 	 3b. Mark the CPU as needing smp_func_module_lp_init()
> 
> Then, in the 'case TDX_MODULE_INITIALIZED:', you call a function to
> iterate over the cpumask that was generated in 3b.
> 
> That makes the handoff *EXPLICIT*.  You know exactly which CPUs need
> what done to them.  A CPU hotplug either explicitly involves doing the
> work to make TDX work on the CPU, or explicitly defers the work to a
> specific later time in a specific later piece of code.

In 3b. we don't need to "explicitly mark the  CPU as needing
smp_func_module_lp_init()".  We already have __cpu_tdx_mask to track whether
LP.INIT has been done on one cpu and we can use that to determine:

	Any online cpu which isn't set in __cpu_tdx_mask needs to do LP.INIT in
	tdx_enable().

And the function module_lp_init_online_cpus() already handles that, and it can
be called directly in tdx_enable() path (as shown in this patch).

I'll do above as you suggested, but just use __cpu_tdx_mask as explained above.

( My main concern is "Run after the KVM handler" seems a little bit hacky to me.
Logically, it's more reasonable to have the TDX callback _before_ KVM's but not
_after_.  If any user (KVM) has done tdx_enable() successfully, the TDX code
should give the user a "TDX-runnable" cpu before user (KVM)'s own callback is
involved. Anyway as mentioned above, I'll do above as you suggested.)

  reply	other threads:[~2023-02-13 23:43 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-13 11:59 [PATCH v9 00/18] TDX host kernel support Kai Huang
2023-02-13 11:59 ` [PATCH v9 01/18] x86/tdx: Define TDX supported page sizes as macros Kai Huang
2023-02-13 11:59 ` [PATCH v9 02/18] x86/virt/tdx: Detect TDX during kernel boot Kai Huang
2023-02-13 11:59 ` [PATCH v9 03/18] x86/virt/tdx: Make INTEL_TDX_HOST depend on X86_X2APIC Kai Huang
2023-02-13 11:59 ` [PATCH v9 04/18] x86/virt/tdx: Add skeleton to initialize TDX on demand Kai Huang
2023-02-14 12:46   ` Peter Zijlstra
2023-02-14 17:23     ` Dave Hansen
2023-02-14 21:08       ` Huang, Kai
2023-02-13 11:59 ` [PATCH v9 05/18] x86/virt/tdx: Add SEAMCALL infrastructure Kai Huang
2023-02-13 17:48   ` Dave Hansen
2023-02-13 21:21     ` Huang, Kai
2023-02-13 22:39   ` Dave Hansen
2023-02-13 23:22     ` Huang, Kai
2023-02-14  8:57       ` Huang, Kai
2023-02-14 17:27         ` Dave Hansen
2023-02-14 22:17           ` Huang, Kai
2023-02-14 12:42   ` Peter Zijlstra
2023-02-14 21:02     ` Huang, Kai
2023-02-13 11:59 ` [PATCH v9 06/18] x86/virt/tdx: Do TDX module global initialization Kai Huang
2023-02-13 11:59 ` [PATCH v9 07/18] x86/virt/tdx: Do TDX module per-cpu initialization Kai Huang
2023-02-13 17:59   ` Dave Hansen
2023-02-13 21:19     ` Huang, Kai
2023-02-13 22:43       ` Dave Hansen
2023-02-14  0:02         ` Huang, Kai
2023-02-14 14:12           ` Peter Zijlstra
2023-02-14 22:53             ` Huang, Kai
2023-02-15  9:16               ` Peter Zijlstra
2023-02-15  9:46                 ` Huang, Kai
2023-02-15 13:25                   ` Peter Zijlstra
2023-02-15 21:37                     ` Huang, Kai
2023-03-06 14:26                       ` Huang, Kai
2023-02-13 18:07   ` Dave Hansen
2023-02-13 21:13     ` Huang, Kai
2023-02-13 22:28       ` Dave Hansen
2023-02-13 23:43         ` Huang, Kai [this message]
2023-02-13 23:52           ` Dave Hansen
2023-02-14  0:09             ` Huang, Kai
2023-02-14 14:12     ` Peter Zijlstra
2023-02-14 12:59   ` Peter Zijlstra
2023-02-13 11:59 ` [PATCH v9 08/18] x86/virt/tdx: Get information about TDX module and TDX-capable memory Kai Huang
2023-02-13 11:59 ` [PATCH v9 09/18] x86/virt/tdx: Use all system memory when initializing TDX module as TDX memory Kai Huang
2023-02-14  3:30   ` Huang, Ying
2023-02-14  8:24     ` Huang, Kai
2023-02-13 11:59 ` [PATCH v9 10/18] x86/virt/tdx: Add placeholder to construct TDMRs to cover all TDX memory regions Kai Huang
2023-02-13 11:59 ` [PATCH v9 11/18] x86/virt/tdx: Fill out " Kai Huang
2023-02-13 11:59 ` [PATCH v9 12/18] x86/virt/tdx: Allocate and set up PAMTs for TDMRs Kai Huang
2023-02-13 11:59 ` [PATCH v9 13/18] x86/virt/tdx: Designate reserved areas for all TDMRs Kai Huang
2023-02-13 11:59 ` [PATCH v9 14/18] x86/virt/tdx: Configure TDX module with the TDMRs and global KeyID Kai Huang
2023-02-13 11:59 ` [PATCH v9 15/18] x86/virt/tdx: Configure global KeyID on all packages Kai Huang
2023-02-13 11:59 ` [PATCH v9 16/18] x86/virt/tdx: Initialize all TDMRs Kai Huang
2023-02-13 11:59 ` [PATCH v9 17/18] x86/virt/tdx: Flush cache in kexec() when TDX is enabled Kai Huang
2023-02-13 11:59 ` [PATCH v9 18/18] Documentation/x86: Add documentation for TDX host support 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=8e9238bbcccedfa00e2dbec87e1d77d370911846.camel@intel.com \
    --to=kai.huang@intel.com \
    --cc=ak@linux.intel.com \
    --cc=bagasdotme@gmail.com \
    --cc=chao.gao@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=david@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=isaku.yamahata@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=linux-mm@kvack.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=reinette.chatre@intel.com \
    --cc=sagis@google.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=ying.huang@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.