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] [thread-next>] [day] [month] [year] [list]

Message-ID: <BL1PR11MB55255A7D0148F35E58FE37F3F70EA@BL1PR11MB5525.namprd11.prod.outlook.com>
Date: Wed, 10 Sep 2025 20:52:41 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: Arjan van de Ven <arjan@...ux.intel.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

Sure.  Fine to me to just always on.