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

[Yosry Ahmed]

On Fri, Feb 27, 2026 at 7:33 PM Kevin Cheng <chengkev@xxxxxxxxxx> wrote:
>
> The APM lists the following behaviors
>   - The VMRUN, VMLOAD, VMSAVE, CLGI, VMMCALL, and INVLPGA instructions
>     can be used when the EFER.SVME is set to 1; otherwise, these
>     instructions generate a #UD exception.
>   - If VMMCALL instruction is not intercepted, the instruction raises a
>     #UD exception.
>
> The patches in this series fix current SVM bugs that do not adhere to
> the APM listed behaviors.
>
> v3 -> v4:
>   - Dropped "KVM: SVM: Inject #UD for STGI if EFER.SVME=0 and SVM Lock
>     and DEV are not available" as per Sean
>   - Added back STGI and CLGI intercept clearing in init_vmcb to maintain
>     previous behavior on intel guests. Previously intel guests always
>     had STGI and CLGI intercepts cleared if vgif was enabled. In V3,
>     because the clearing of the intercepts was moved from init_vmcb() to
>     the !guest_cpuid_is_intel_compatible() case in
>     svm_recalc_instruction_intercepts(), the CLGI intercept would be
>     indefinitely set on intel guests. I added back the clearing to
>     init_vmcb() to retain intel guest behavior before this patch.

I am a bit confused by this. v4 kept initializing the intercepts as
cleared for all guests, but we still set the CLGI/STGI intercepts for
Intel-compatible guests in svm_recalc_instruction_intercepts() patch
3. So what difference did this make?

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?



>   - In "Raise #UD if VMMCALL instruction is not intercepted" patch:
>       - Exempt Hyper-V L2 TLB flush hypercalls from the #UD injection,
>         as L0 intentionally intercepts these VMMCALLs on behalf of L1
>         via the direct hypercall enlightenment.
>       - Added nested_svm_is_l2_tlb_flush_hcall() which just returns true
>         if the hypercall was a Hyper-V L2 TLB flush hypercall.
>
> v3: https://lore.kernel.org/kvm/20260122045755.205203-1-chengkev@xxxxxxxxxx/
>
> v2 -> v3:
>   - Elaborated on 'Move STGI and CLGI intercept handling' commit message
>     as per Sean
>   - Fixed bug due to interaction with svm_enable_nmi_window() and 'Move
>     STGI and CLGI intercept handling' as pointed out by Yosry. Code
>     changes suggested by Sean/Yosry.
>   - Removed open-coded nested_svm_check_permissions() in STGI
>     interception function as per Yosry
>
> v2: https://lore.kernel.org/all/20260112174535.3132800-1-chengkev@xxxxxxxxxx/
>
> v1 -> v2:
>   - Split up the series into smaller more logical changes as suggested
>     by Sean
>   - Added patch for injecting #UD for STGI under APM defined conditions
>     as suggested by Sean
>   - Combined EFER.SVME=0 conditional with intel CPU logic in
>     svm_recalc_instruction_intercepts
>
> Kevin Cheng (4):
>   KVM: SVM: Move STGI and CLGI intercept handling
>   KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0
>   KVM: SVM: Recalc instructions intercepts when EFER.SVME is toggled
>   KVM: SVM: Raise #UD if VMMCALL instruction is not intercepted
>
>  arch/x86/kvm/svm/hyperv.h | 11 ++++++++
>  arch/x86/kvm/svm/nested.c |  4 +--
>  arch/x86/kvm/svm/svm.c    | 59 +++++++++++++++++++++++++++++++++++----
>  3 files changed, 65 insertions(+), 9 deletions(-)
>
> --
> 2.53.0.473.g4a7958ca14-goog
>