All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: vmx_pmu_caps_test fails on Skylake based CPUS due to read only LBRs
Date: Wed, 22 Jan 2025 13:02:25 -0800	[thread overview]
Message-ID: <Z5Fc4d5bVf5oVlOk@google.com> (raw)
In-Reply-To: <dd128607c0306d21e57994ffb964514728b92f29.camel@redhat.com>

On Wed, Jan 22, 2025, Maxim Levitsky wrote:
> On Tue, 2025-01-21 at 17:02 -0800, Sean Christopherson wrote:
> > On Sun, Nov 03, 2024, Maxim Levitsky wrote:
> > > On Mon, 2024-10-28 at 08:55 -0700, Sean Christopherson wrote:
> > > > On Fri, Oct 18, 2024, Maxim Levitsky wrote:
> > > > > Our CI found another issue, this time with vmx_pmu_caps_test.
> > > > > 
> > > > > On 'Intel(R) Xeon(R) Gold 6328HL CPU' I see that all LBR msrs (from/to and
> > > > > TOS), are always read only - even when LBR is disabled - once I disable the
> > > > > feature in DEBUG_CTL, all LBR msrs reset to 0, and you can't change their
> > > > > value manually.  Freeze LBRS on PMI seems not to affect this behavior.
> > 
> > ...
> > 
> > > When DEBUG_CTL.LBR=1, the LBRs do work, I see all the registers update,
> > > although TOS does seem to be stuck at one value, but it does change
> > > sometimes, and it's non zero.
> > > 
> > > The FROM/TO do show healthy amount of updates 
> > > 
> > > Note that I read all msrs using 'rdmsr' userspace tool.
> > 
> > I'm pretty sure debugging via 'rdmsr', i.e. /dev/msr, isn't going to work.  I
> > assume perf is clobbering LBR MSRs on context switch, but I haven't tracked that
> > down to confirm (the code I see on inspecition is gated on at least one perf
> > event using LBRs).  My guess is that there's a software bug somewhere in the
> > perf/KVM exchange.
> > 
> > I confirmed that using 'rdmsr' and 'wrmsr' "loses" values, but that hacking KVM
> > to read/write all LBRs during initialization works with LBRs disabled.
> 
> Hi,
> 
> OK, this is a very good piece of the puzzle.
> 
> I didn't expect context switch to interfere with this because I thought that
> perf code won't touch LBRs if they are not in use. 
> rdmsr/wrmsr programs don't do much except doing the instruction in the kernel space.
> 
> Is it then possible that the the fact that LBRs were left enabled by BIOS is the
> culprit of the problem?
> 
> This particular test never enables LBRs, not anything in the system does this,

Ugh, but it does.  On writes to any LBR, including LBR_TOS, KVM creates a "virtual"
LBR perf event.  KVM then relies on perf to context switch LBR MSRs, i.e. relies
on perf to load the guest's values into hardware.  At least, I think that's what
is supposed to happen.  AFAIK, the perf-based LBR support has never been properly
document[*].

Anyways, my understanding of intel_pmu_handle_lbr_msrs_access() is that if the
vCPU's LBR perf event is scheduled out or can't be created, the guest's value is
effectively lost.  Again, I don't know the "rules" for the LBR perf event, but
it wouldn't suprise me if your CI fails because something in the host conflicts
with KVM's LBR perf event.

[*] https://lore.kernel.org/all/Y9RUOvJ5dkCU9J8C@google.com

  reply	other threads:[~2025-01-22 21:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-19  0:48 vmx_pmu_caps_test fails on Skylake based CPUS due to read only LBRs Maxim Levitsky
2024-10-28 15:55 ` Sean Christopherson
2024-11-03 23:32   ` Maxim Levitsky
2024-11-22  3:35     ` Maxim Levitsky
2024-12-14  0:20       ` Maxim Levitsky
2025-01-21 22:56         ` Maxim Levitsky
2025-01-22  1:02     ` Sean Christopherson
2025-01-22 16:36       ` Maxim Levitsky
2025-01-22 21:02         ` Sean Christopherson [this message]
2025-01-24 23:36           ` Maxim Levitsky
2025-01-25  0:12             ` Sean Christopherson
2025-01-27 17:58               ` Maxim Levitsky

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=Z5Fc4d5bVf5oVlOk@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlevitsk@redhat.com \
    /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.