Re: [PATCH V4 0/4] Align SVM with APM defined behaviors

[Kevin Cheng]

On Mon, Mar 2, 2026 at 7:35 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Mon, Mar 02, 2026, Sean Christopherson wrote:
> > On Mon, Mar 02, 2026, Sean Christopherson wrote:
> > > On Mon, Mar 02, 2026, Yosry Ahmed wrote:
> > > > Also taking a step back, I am not really sure what's the right thing
> > > > to do for Intel-compatible guests here. It also seems like even if we
> > > > set the intercept, svm_set_gif() will clear the STGI intercept, even
> > > > on Intel-compatible guests.
> > > >
> > > > Maybe we should leave that can of worms alone, go back to removing
> > > > initializing the CLGI/STGI intercepts in init_vmcb(), and in
> > > > svm_recalc_instruction_intercepts() set/clear these intercepts based
> > > > on EFER.SVME alone, irrespective of Intel-compatibility?
> > >
> > > Ya, guest_cpuid_is_intel_compatible() should only be applied to VMLOAD/VMSAVE.
> > > KVM intercepts VMLOAD/VMSAVE to fixup SYSENTER MSRs, not to inject #UD.  I.e. KVM
> > > is handling (the absoutely absurd) case that FMS reports an Intel CPU, but the
> > > guest enables and uses SVM.
> > >
> > >     /*
> > >      * Intercept VMLOAD if the vCPU model is Intel in order to emulate that
> > >      * VMLOAD drops bits 63:32 of SYSENTER (ignoring the fact that exposing
> > >      * SVM on Intel is bonkers and extremely unlikely to work).
> > >      */
> > >     if (guest_cpuid_is_intel_compatible(vcpu))
> > >             guest_cpu_cap_clear(vcpu, X86_FEATURE_V_VMSAVE_VMLOAD);
> > >
> > > Sorry for not catching this in previous versions.
> >
> > Because I got all kinds of confused trying to recall what was different between
> > v3 and v4, I went ahead and spliced them together.
> >
> > Does the below look right?  If so, I'll formally post just patches 1 and 3 as v5.
> > I'll take 2 and 4 directly from here; I want to switch the ordering anyways so
> > that the vgif movement immediately precedes the Recalc "instructions" patch.
>
> Actually, I partially take that back.  I'm going to send a separate v5 for patch
> 4, as there are additional cleanups that can be done related to Hyper-V stubs.
>

Gotcha, if you're sending just patch 4 as v5, then should I send
patches 1 and 3 (with fixes) as a new series?

> P.S. This is a good example of why bundling unrelated patches into series is
> discouraged.
>

Noted :)