From: Sean Christopherson <seanjc@google.com>
To: Yosry Ahmed <yosry.ahmed@linux.dev>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] KVM: SVM: Fix redundant updates of LBR MSR intercepts
Date: Mon, 17 Nov 2025 09:03:41 -0800 [thread overview]
Message-ID: <aRtVbeVHe5ZFOPQW@google.com> (raw)
In-Reply-To: <ei6cdmnvhzyavfobamjkcq2ghdrxcv7ruxhcbzzycqlvaty7zr@5cjkfczxiqom>
On Fri, Nov 14, 2025, Yosry Ahmed wrote:
> On Fri, Nov 14, 2025 at 08:34:54AM -0800, Sean Christopherson wrote:
> > On Wed, Nov 12, 2025, Yosry Ahmed wrote:
> > > svm_update_lbrv() always updates LBR MSRs intercepts, even when they are
> > > already set correctly. This results in force_msr_bitmap_recalc always
> > > being set to true on every nested transition,
> >
> > Nit, it's only on VMRUN, not on every transition (i.e. not on nested #VMEXIT).
>
> How so? svm_update_lbrv() will also be called in nested_svm_vmexit(),
> and it will eventually lead to force_msr_bitmap_recalc being set to
> true.
>
> I guess what you meant is the "undoing the Hyper-V optimization" part.
> That is indeed only affected by the svm_update_lbrv() call in the nested
> VMRUN path.
Ooh, yeah, my mind was fully on when the intercepts would be recomputed, not on
when the flag could be set.
next prev parent reply other threads:[~2025-11-17 17:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-12 1:30 [PATCH] KVM: SVM: Fix redundant updates of LBR MSR intercepts Yosry Ahmed
2025-11-14 16:34 ` Sean Christopherson
2025-11-14 16:52 ` Yosry Ahmed
2025-11-17 17:03 ` Sean Christopherson [this message]
2025-11-17 18:38 ` Paolo Bonzini
-- strict thread matches above, loose matches on Subject: below --
2025-12-15 19:26 Yosry Ahmed
2025-12-15 19:33 ` Yosry Ahmed
2025-12-15 19:38 ` Sean Christopherson
2025-12-15 20:10 ` Yosry Ahmed
2026-01-14 22:07 ` Sean Christopherson
2026-01-15 0:35 ` Yosry Ahmed
2026-01-15 1:12 ` Sean Christopherson
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=aRtVbeVHe5ZFOPQW@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=stable@vger.kernel.org \
--cc=yosry.ahmed@linux.dev \
/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.