linux-kernel - Re: [RFC PATCH v1 0/5] x86/boot, KVM: Move VMXON/VMXOFF handling from KVM to CPU lifecycle

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: <CALMp9eTZ7TA8RLSkJYPAawQjVVT9pFxB4QzAjs6XhzHJvQ=V3w@mail.gmail.com>
Date: Tue, 16 Sep 2025 11:25:41 -0700
From: Jim Mattson <jmattson@...gle.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Arjan van de Ven <arjan@...ux.intel.com>, "Xin Li (Intel)" <xin@...or.com>, linux-kernel@...r.kernel.org, 
	kvm@...r.kernel.org, linux-pm@...r.kernel.org, pbonzini@...hat.com, 
	tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, 
	dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com, rafael@...nel.org, 
	pavel@...nel.org, brgerst@...il.com, david.kaplan@....com, 
	peterz@...radead.org, andrew.cooper3@...rix.com, kprateek.nayak@....com, 
	chao.gao@...el.com, rick.p.edgecombe@...el.com, dan.j.williams@...el.com
Subject: Re: [RFC PATCH v1 0/5] x86/boot, KVM: Move VMXON/VMXOFF handling from
 KVM to CPU lifecycle

On Tue, Sep 16, 2025 at 10:54 AM Sean Christopherson <seanjc@...gle.com> wrote:
>
> On Thu, Sep 11, 2025, Arjan van de Ven wrote:
> > Hi,
> > > I also want to keep the code as a module, both to avoid doing VMXON unconditionally,
> >
> > can you expand on what the problem is with having VMXON unconditionally enabled?
>
> Unlike say EFER.SVME, VMXON fundamentally changes CPU behavior.  E.g. blocks INIT,
> activates VMCS caches (which aren't cleared by VMXOFF on pre-SPR CPUs, and AFAIK
> Intel hasn't even publicly committed to that behavior for SPR+), restricts allowed
> CR0 and CR4 values, raises questions about ucode patch updates, triggers unique
> flows in SMI/RSM, prevents Intel PT from tracing on certain CPUs, and probably a
> few other things I'm forgetting.

Do we leave VMX operation today when applying a late-load microcode patch?

> > A lot of things are much simpler if it's on at cpu up, and turned off only at the
> > down path (be it offline of kexec).. no refcounting, no locking, etc...
>
> For Intel.  Unless _all_ vendors and architectures follow suit, KVM will need
> the refcounting and locking.  And while it's not anyone's fault, the *vast*
> majority of complexity around enabling virtualization in KVM is due to VMX.
> I.e. KVM added a bunch of code to deal with the aformentioned side effects of
> VMXON, and as a result, all other vendors/architectures have had to deal with
> that complexity.
>
> > so would be good to understand what the problem would be with having it always on
>
> Doing VMXON unconditionally is a minor objection.  My primary objection is that
> this series does what's easiest for TDX, and leaves behind all of the VMX-induced
> technical debt in KVM.
>