public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Jim Mattson <jmattson@google.com>
Cc: Gao Shiyuan <gaoshiyuan@baidu.com>,
	pbonzini@redhat.com, x86@kernel.org, kvm@vger.kernel.org,
	likexu@tencent.com
Subject: Re: [PATCH] KVM: x86/vPMU: ignore the check of IA32_PERF_GLOBAL_CTRL bit35
Date: Fri, 2 Jun 2023 12:16:36 -0700	[thread overview]
Message-ID: <ZHpAFOw/RW/ZRpi2@google.com> (raw)
In-Reply-To: <CALMp9eRWJ9H3oY9utMs5auTM-BSCer=XA+Lsr9QVBqkFFDCFQw@mail.gmail.com>

On Fri, Jun 02, 2023, Jim Mattson wrote:
> On Fri, Jun 2, 2023 at 12:18 AM Gao Shiyuan <gaoshiyuan@baidu.com> wrote:
> >
> > From: Shiyuan Gao <gaoshiyuan@baidu.com>
> >
> > When live-migrate VM on icelake microarchitecture, if the source
> > host kernel before commit 2e8cd7a3b828 ("kvm: x86: limit the maximum
> > number of vPMU fixed counters to 3") and the dest host kernel after this
> > commit, the migration will fail.
> >
> > The source VM's CPUID.0xA.edx[0..4]=4 that is reported by KVM and
> > the IA32_PERF_GLOBAL_CTRL MSR is 0xf000000ff. However the dest VM's
> > CPUID.0xA.edx[0..4]=3 and the IA32_PERF_GLOBAL_CTRL MSR is 0x7000000ff.
> > This inconsistency leads to migration failure.

IMO, this is a userspace bug.  KVM provided userspace all the information it needed
to know that the target is incompatible (3 counters instead of 4), it's userspace's
fault for not sanity checking that the target is compatible.

I agree that KVM isn't blame free, but hacking KVM to cover up userspace mistakes
everytime a feature appears or disappears across kernel versions or configs isn't
maintainable.

> > The QEMU limits the maximum number of vPMU fixed counters to 3, so ignore
> > the check of IA32_PERF_GLOBAL_CTRL bit35.

Unconditionally allowing the bit is unsafe, e.g. will cause KVM to miss consistency
checks on PERF_GLOBAL_CTRL when emulating nested VM-Enter.  They should eventually
be caught by hardware, but it's still undesirable.

> Today, the fixed counters are limited to 3, but I hope we get support
> for top down slots soon.

Is there any reason KVM can't simply add support for the fourth fixed counter?
Perf is already aware of the topdown slots event, so isn't this "just" a matter
of adding the appropriate entries?

> Perhaps this inconsistency is best addressed with a quirk?

*If* we ended up adding a hack to KVM, I'd prefer not to add a quirk, this shouldn't
be something KVM needs to carry long term.

  reply	other threads:[~2023-06-02 19:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-02  7:02 [PATCH] KVM: x86/vPMU: ignore the check of IA32_PERF_GLOBAL_CTRL bit35 Gao Shiyuan
2023-06-02 18:43 ` Jim Mattson
2023-06-02 19:16   ` Sean Christopherson [this message]
2023-06-02 19:30     ` Jim Mattson
2023-06-02 21:48       ` Sean Christopherson
2023-06-02 22:38         ` Jim Mattson
2023-06-02 22:52           ` Sean Christopherson
2023-06-02 23:09             ` Jim Mattson
2023-06-05  3:53               ` Gao,Shiyuan
2023-06-13 21:00                 ` Sean Christopherson
2023-06-14 12:36                   ` Gao,Shiyuan
2023-06-05  3:31             ` Gao,Shiyuan

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=ZHpAFOw/RW/ZRpi2@google.com \
    --to=seanjc@google.com \
    --cc=gaoshiyuan@baidu.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=likexu@tencent.com \
    --cc=pbonzini@redhat.com \
    --cc=x86@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