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>,
"Chatre, Reinette" <reinette.chatre@intel.com>, "Christopherson,,
Sean" <seanjc@google.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"Yamahata, Isaku" <isaku.yamahata@intel.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"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 05/18] x86/virt/tdx: Add SEAMCALL infrastructure
Date: Tue, 14 Feb 2023 22:17:46 +0000 [thread overview]
Message-ID: <e06853c48d7dcb6aa44ce88a23fbe650f01ae8c0.camel@intel.com> (raw)
In-Reply-To: <5f29c397-d723-a18e-e0f0-660f9f22d998@intel.com>
On Tue, 2023-02-14 at 09:27 -0800, Dave Hansen wrote:
> On 2/14/23 00:57, Huang, Kai wrote:
> > Consider this case:
> >
> > 1) KVM does VMXON for all online cpus (a VM created)
> > 2) Another kernel component is calling tdx_enable()
> > 3) KVM does VMXOFF for all online cpus (last VM is destroyed)
>
> Doctor, it hurts when I...
>
> Then let's just call tdx_enable() from other kernel components.
>
> Kai, I'm worried that this is, again, making things more complicated
> than they have to be.
The handling of #UD/#GP itself only takes ~10 LoC. All those complicated logic
comes from we depend on caller of TDX to ensure VMXON has been done.
AFAICT we have below options:
1) Don't support VMXON in the core-kernel, then
1.a Handle #UD/#GP in assembly as shown in this patch; Or
1.b Disable interrupt from CR4.VMXE check until SEAMCALL is done in
seamcall().
2) Let's support VMXON in the core-kernel (by moving VMXON from KVM to the core-
x86), then we get rid of all above. We explicitly do VMXON (if haven't done)
inside tdx_enable() to make sure SEAMCALL doesn't cause #UD. No #UD/#GP
handling is needed in assembly. No interrupt disable in seamcall().
(well #GP can theoretically still happen if BIOS is buggy, we can keep assembly
code change if it's better -- just ~10 LoC).
Supporting VMXON in the core-kernel also has other advantages:
1) We can get rid of the logic to always try to do LP.INIT for all online cpus.
LP.INIT can just be done: a) during module initialization; b) in TDX CPU hotplug
callback.
2) The TDX CPU hotplug callback can just do VMXON and LP.INIT. No CR4.VMXE
check is needed. And it can be put before KVM (all TDX users)' hotplug
callback.
The downside of supporting VMXON to the core-kernel:
1) Need patch(es) to change KVM, so those patches need to be reviewed by KVM
maintainers.
2) No other cons.
Logically, supporting VMXON in the core-kernel makes things simple. And long-
termly, I _think_ we will need it to support future TDX features.
The effort to support VMXON in the core-kernel would be ~300 LOC. I can already
utilize some old patches, but need to polish those patches and do some test.
What's your thinking?
next prev parent reply other threads:[~2023-02-14 22:18 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 [this message]
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
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=e06853c48d7dcb6aa44ce88a23fbe650f01ae8c0.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 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).