Re: [PATCH 6.18.y] KVM: SVM: Stop toggling virtual VMSAVE/VMLOAD on intercept recalc

[Sean Christopherson]

On Mon, Oct 19, 2026, Yosry Ahmed wrote:
> From: Yosry Ahmed <yosry.ahmed@xxxxxxxxx>
> 
> [ Upstream commit 55780d8a1dcc93d2c4b33c565ada88df12c9f206 ]
> 
> Virtual VMSAVE/VMLOAD enablement (i.e.
> VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK) is set/cleared by
> svm_recalc_instruction_intercepts() when the intercepts are cleared/set.
> This is unnecessary because the bit is meaningless when intercepts are
> set and KVM emulates the instructions. Initialize the bit in vmcb01 base
> on vls, and keep it unchanged.
> 
> This is similar-ish to how vGIF is handled. It is enabled in init_vmcb()
> if vgif=1 and remains unchanged when the STGI intercept is enabled (e.g.
> for NMI windows).
> 
> This fixes a bug in svm_recalc_instruction_intercepts(). The intercepts
> for VMSAVE/VMLOAD are always toggled in vmcb01, but
> VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK is toggled in the current VMCB, which
> could be vmcb02 instead of vmcb01 if L2 is active.
> 
> Virtual VMSAVE/VMLOAD enablement in vmcb02 is separately controlled by
> nested_vmcb02_prepare_control() based on the vCPU features and VMCB12,
> and if intercepts are needed they are set by recalc_intercepts().
> 
> The bug is benign though. Not toggling the bit for vmcb01 is harmless
> because it's useless anyway. For vmcb02:
> 
> - The bit could be incorrectly cleared when intercepts are set in
>   vmcb01. This is harmless because VMSAVE/VMLOAD will be emulated by KVM
>   anyway.
> 
> - The bit could be incorrectly set when the intercepts are cleared in
>   vmcb01. However, if the bit was originally clear in vmcb02, then
>   recalc_intercepts() will enable in the intercepts in vmcb02 anyway and
>   VMSAVE/VMLOAD will be emulated by KVM.
> 
> Signed-off-by: Yosry Ahmed <yosry.ahmed@xxxxxxxxx>
> Link: https://patch.msgid.link/20260110004821.3411245-3-yosry.ahmed@xxxxxxxxx
> Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
> Fixes: 5a1a726e68ff ("KVM: x86: Use KVM_REQ_RECALC_INTERCEPTS to react to CPUID updates")
> Reported-by: Nikola Ciprich <nikola.ciprich@xxxxxxxxxxx>
> Closes: https://lore.kernel.org/linux-mm/arY1Wq6R9OY20ans@xxxxxxxxxxxxxxxxx/
> Tested-by: Nikola Ciprich <nikola.ciprich@xxxxxxxxxxx>
> [ yosry: The bug is not benign. Since 5a1a726e68ff, a vCPU restored into
>   L2 (e.g. on live migration) recalculates intercepts with vmcb02
>   loaded, leaving vmcb01 with neither VMLOAD/VMSAVE intercepts nor
>   virtual VMLOAD/VMSAVE, so L1's VMLOAD/VMSAVE corrupt host memory. ]
> Signed-off-by: Yosry Ahmed <yosry@xxxxxxxxxx>
> ---

Acked-by: Sean Christopherson <seanjc@xxxxxxxxxx>