Re: [PATCH v2 1/3] KVM: x86: Explicitly configure supported XSS from {svm,vmx}_set_cpu_caps()

[Sean Christopherson <seanjc@google.com>]

On Thu, Jan 29, 2026, Xiaoyao Li wrote:
> On 1/28/2026 9:43 AM, Sean Christopherson wrote:
> > Explicitly configure KVM's supported XSS as part of each vendor's setup
> > flow to fix a bug where clearing SHSTK and IBT in kvm_cpu_caps, e.g. due
> > to lack of CET XFEATURE support, makes kvm-intel.ko unloadable when nested
> > VMX is enabled, i.e. when nested=1.  The late clearing results in
> > nested_vmx_setup_{entry,exit}_ctls() clearing VM_{ENTRY,EXIT}_LOAD_CET_STATE
> > when nested_vmx_setup_ctls_msrs() runs during the CPU compatibility checks,
> > ultimately leading to a mismatched VMCS config due to the reference config
> > having the CET bits set, but every CPU's "local" config having the bits
> > cleared.
> > 
> > Note, kvm_caps.supported_{xcr0,xss} are unconditionally initialized by
> > kvm_x86_vendor_init(), before calling into vendor code, and not referenced
> > between ops->hardware_setup() and their current/old location.
> 
> I'm thinking whether to move the initialization of supported_xss from
> kvm_x86_vendor_init() to kvm_setup_xss_caps(). Anyway it can be a separate
> patch, if we agree to make the change.

Hmm, I definitely don't want to do that, because then we'll end up with asymmetric
initialization of kvm_caps.*, and I don't want to move that initialization under
{svm,vmx}_set_cpu_caps() because it's pretty much guaranteed to lead to different
ordering issues.

One idea would be to call the new API kvm_finalize_xss_caps() instead of
kvm_setup_xss_caps(), but I'm not sure I like that idea.  Or maybe
kvm_constrain_xss_caps()?  That feels awkward and unintuitive though.

All in all, I agree that having a "setup" API rely on prior initialization is a
bit wonky, but I don't love any of the alternatives either. :-/