From: Sean Christopherson <seanjc@google.com>
To: Yosry Ahmed <yosry@kernel.org>
Cc: stable@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Jim Mattson <jmattson@google.com>,
Kevin Cheng <chengkev@google.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
david@kernel.org, Lorenzo Stoakes <ljs@kernel.org>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
David Laight <david.laight.linux@gmail.com>,
Kiryl Shutsemau <kas@kernel.org>,
Lance Yang <lance.yang@linux.dev>,
Luiz Capitulino <luizcap@redhat.com>,
Matt Fleming <matt@readmodwrite.com>,
Pedro Falcato <pfalcato@suse.de>,
Rik van Riel <riel@surriel.com>, Mike Rapoport <rppt@kernel.org>,
Tal Zussman <tz2294@columbia.edu>,
andrew.cooper3@citrix.com, gregkh@linuxfoundation.org,
sashal@kernel.org, Yosry Ahmed <yosry.ahmed@linux.dev>,
Nikola Ciprich <nikola.ciprich@linuxbox.cz>
Subject: Re: [PATCH 6.18.y] KVM: SVM: Stop toggling virtual VMSAVE/VMLOAD on intercept recalc
Date: Tue, 20 Oct 2026 06:04:47 -0700 [thread overview]
Message-ID: <atdm23p9cUTG7_MX@google.com> (raw)
In-Reply-To: <20261019214611.404880-1-yosry@kernel.org>
On Mon, Oct 19, 2026, Yosry Ahmed wrote:
> From: Yosry Ahmed <yosry.ahmed@linux.dev>
>
> [ 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@linux.dev>
> Link: https://patch.msgid.link/20260110004821.3411245-3-yosry.ahmed@linux.dev
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> Fixes: 5a1a726e68ff ("KVM: x86: Use KVM_REQ_RECALC_INTERCEPTS to react to CPUID updates")
> Reported-by: Nikola Ciprich <nikola.ciprich@linuxbox.cz>
> Closes: https://lore.kernel.org/linux-mm/arY1Wq6R9OY20ans@pcnci.linuxbox.cz/
> Tested-by: Nikola Ciprich <nikola.ciprich@linuxbox.cz>
> [ 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@kernel.org>
> ---
Acked-by: Sean Christopherson <seanjc@google.com>
prev parent reply other threads:[~2026-10-20 13:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 21:46 [PATCH 6.18.y] KVM: SVM: Stop toggling virtual VMSAVE/VMLOAD on intercept recalc Yosry Ahmed
2026-10-20 13:04 ` Sean Christopherson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atdm23p9cUTG7_MX@google.com \
--to=seanjc@google.com \
--cc=akpm@linux-foundation.org \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=chengkev@google.com \
--cc=dave.hansen@linux.intel.com \
--cc=david.laight.linux@gmail.com \
--cc=david@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jmattson@google.com \
--cc=kas@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=luizcap@redhat.com \
--cc=matt@readmodwrite.com \
--cc=nikola.ciprich@linuxbox.cz \
--cc=pbonzini@redhat.com \
--cc=pfalcato@suse.de \
--cc=riel@surriel.com \
--cc=rppt@kernel.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tz2294@columbia.edu \
--cc=yosry.ahmed@linux.dev \
--cc=yosry@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox