Re: [PATCH 2/4] KVM: VMX: Refresh LBR MSR intercepts on full MSR intercept recalc

[Sean Christopherson <seanjc@google.com>]

On Wed, Nov 04, 2026, Jim Mattson wrote:
> On Wed, Nov 4, 2026 at 3:49 PM Jim Mattson <jmattson@google.com> wrote:
> >
> > On Wed, Nov 4, 2026 at 12:45 PM Sean Christopherson <seanjc@google.com> wrote:
> > >
> > > On Tue, Oct 20, 2026, Jim Mattson wrote:
> > > > Re-apply the LBR MSR intercepts in vmx_recalc_msr_intercepts() if the
> > > > LBRs are currently passed through, so that changes to userspace MSR
> > > > filters are reflected in the MSR bitmap.  Unlike SVM, which can simply
> > > > rewrite the intercepts in either direction, leave the bitmap alone if
> > > > the LBRs aren't passed through, as a filter can only force interception,
> > > > never prevent it, i.e. the bitmap is already correct.  Note, clearing
> > > > msr_passthrough to force vmx_passthrough_lbr_msrs() to re-apply the
> > > > intercepts on the next VM-Enter isn't an option, as doing so would
> > > > leave stale passthrough bits behind if the guest LBR event is no longer
> > > > active.
> > > >
> > > > vmx_recalc_msr_intercepts() is invoked in response to
> > > > KVM_REQ_RECALC_INTERCEPTS, which is raised on MSR filter updates, but it
> > > > skips the LBR MSRs, and vmx_enable_lbr_msrs_passthrough() does nothing
> > > > if lbr_desc->msr_passthrough is already set.  If the LBR MSRs are passed
> > > > through when userspace installs a filter that denies them, they remain
> > > > passed through, and the guest can access them without exiting to
> > > > userspace.  Conversely, if a filter forced interception when the guest
> > > > LBR event became active, relaxing the filter leaves the MSRs needlessly
> > > > intercepted.  Either way, the bitmap remains stale until the guest LBR
> > > > event is torn down and recreated.
> > > >
> > > > Only x2APIC MSRs are exempt from userspace filtering (see
> > > > kvm_msr_allowed() and the KVM_X86_SET_MSR_FILTER documentation), and the
> > > > filter is honored when LBR passthrough is first enabled, so KVM's
> > > > behavior shouldn't depend on whether the filter is set before or after
> > > > the guest enables LBRs.  Drop the LBR MSRs from the comment claiming
> > > > that they can't be filtered by userspace, and clarify that
> > > > lbr_desc.msr_passthrough tracks KVM's desired interception, which may
> > > > not match the MSR bitmap when userspace filters are in play.
> > > >
> > > > Fixes: 9254beaafd12 ("KVM: vmx/pmu: Reduce the overhead of LBR pass-through or cancellation")
> > > > Cc: stable@vger.kernel.org
> > >
> > > Meh, this isn't stable material.  Unlike SVM, where LBR virtualization is tied
> > > to a pile of other crud, if userspace wants to filter LBRs on Intel it should
> > > just not expose LBRs in the first place.
> >
> > The functionality is not equivalent. For whatever reason, MSR
> > filtering can be modified dynamically.
> 
> Oh, and, duh, MSR filtering doesn't disallow the LBRs; it just
> reflects them to userspace.

Right, but how many real world deployments actually enable vLBR *and* want to
intercept accesses *and* want to do so dynamically?  This isn't a particularly
dangerous change by any means, but sending things to stable@ does incur some
amount of downstream work.  Unless there's an actual end user that's affected by
this flaw, I'd much prefer not to create more work.