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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.