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

[Arjan van de Ven <arjan@linux.intel.com>]

On 9/16/2025 10:54 AM, Sean Christopherson wrote:
  what the problem is with having VMXON unconditionally enabled?
> 
> Unlike say EFER.SVME, VMXON fundamentally changes CPU behavior.  E.g. blocks INIT,

blocking INIT is clearly a thing, and both KVM and this patch series deal with that by vmxoff before offline/kexec/etc cases

> 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+),

the VMCS caches aren't great for sure -- which is why the behavior of having vmx on all the time and only
vmxoff at a "fatal to execution" point (offline, kexec, ..) is making life simpler, by not dealing
with this at runtime


 > 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.

I went through a similar mental list and my conclusion was a bit different.
The behavior changes are minor at best ..
And yes there are a few things different in microcode -- but the reality is that every day millions of
servers and laptops/etc all run with vmxon (by virtue of running KVM or other virtualization)
all day long, day in day out -- and it is not causing any issues at all.

An argument that any supposed behavior change is unacceptable also implies virtualization
itself would run into that same argument... and a LOT of the world runs virtualized.