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

[Sean Christopherson]

On Tue, Mar 03, 2026, Kevin Cheng wrote:
> 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?

No need, I'll send a v5 for 1 and 3 as well.