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

[Jim Mattson]

On Tue, Sep 16, 2025 at 10:54 AM Sean Christopherson <seanjc@xxxxxxxxxx> 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.
>