linux-kernel - Re: [RFC PATCH v1 1/5] x86/boot: Shift VMXON from KVM init to CPU startup phase

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c29abf85-aafe-4cf8-b4e8-6d3b5b250ce6@linux.intel.com>
Date: Wed, 10 Sep 2025 06:13:59 -0700
From: Arjan van de Ven <arjan@...ux.intel.com>
To: "Huang, Kai" <kai.huang@...el.com>, "Gao, Chao" <chao.gao@...el.com>
Cc: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
 "brgerst@...il.com" <brgerst@...il.com>,
 "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
 "x86@...nel.org" <x86@...nel.org>, "rafael@...nel.org" <rafael@...nel.org>,
 "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "seanjc@...gle.com" <seanjc@...gle.com>, "xin@...or.com" <xin@...or.com>,
 "pbonzini@...hat.com" <pbonzini@...hat.com>,
 "mingo@...hat.com" <mingo@...hat.com>,
 "tglx@...utronix.de" <tglx@...utronix.de>, "hpa@...or.com" <hpa@...or.com>,
 "peterz@...radead.org" <peterz@...radead.org>,
 "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
 "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
 "kprateek.nayak@....com" <kprateek.nayak@....com>,
 "pavel@...nel.org" <pavel@...nel.org>,
 "david.kaplan@....com" <david.kaplan@....com>,
 "Williams, Dan J" <dan.j.williams@...el.com>, "bp@...en8.de" <bp@...en8.de>
Subject: Re: [RFC PATCH v1 1/5] x86/boot: Shift VMXON from KVM init to CPU
 startup phase

> 
> Since I think doing VMXON when bringing up CPU unconditionally is a
> dramatic move at this stage, I was actually thinking we don't do VMXON in
> CPUHP callback, but only do prepare things like sanity check and VMXON
> region setup etc.  If anything fails, we refuse to online CPU, or mark CPU
> as VMX not supported, whatever.

the whole point is to always vmxon -- and simplify all the complexity
from doing this dynamic.
So yes "dramatic" maybe but needed -- especially as things like TDX
and TDX connect need vmxon to be enabled outside of KVM context.


> 
> The core kernel then provides two APIs to do VMXON/VMXOFF respectively,
> and KVM can use them.  The APIs needs to handle concurrent requests from
> multiple users, though.  VMCLEAR could still be in KVM since this is kinda
> KVM's internal on how to manage vCPUs.
> 
> Does this make sense?

not to me -- the whole point is to not having this dynamic thing