linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: "Liang, Kan" <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jianfeng Gao <jianfeng.gao@intel.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH] perf/x86: KVM: Disable vPMU support on hybrid CPUs (host PMUs)
Date: Fri, 20 Jan 2023 17:32:21 +0000	[thread overview]
Message-ID: <Y8rQJf3ki8a1aRjW@google.com> (raw)
In-Reply-To: <1dec071d-c010-cd89-9e58-d643e71e775c@linux.intel.com>

On Fri, Jan 20, 2023, Liang, Kan wrote:
> 
> On 2023-01-19 7:40 p.m., Sean Christopherson wrote:
> > Disable KVM support for virtualizing PMUs on hosts with hybrid PMUs until
> > KVM gains a sane way to enumeration the hybrid vPMU to userspace and/or
> > gains a mechanism to let userspace opt-in to the dangers of exposing a
> > hybrid vPMU to KVM guests.
> > 
> > Virtualizing a hybrid PMU, or at least part of a hybrid PMU, is possible,
> > but it requires userspace to pin vCPUs to pCPUs to prevent migrating a
> > vCPU between a big core and a little core, requires the VMM to accurately
> > enumerate the topology to the guest (if exposing a hybrid CPU to the
> > guest), and also requires the VMM to accurately enumerate the vPMU
> > capabilities to the guest.
> 
> Current kernel only return the common counters to KVM, which is
> available on both e-core and p-core. In theory, there should be no
> problem with the migration between cores. You don't have to pin vCPU.
> The only problem is that you probably can only use the architecture events.

And how exactly is KVM supposed to tell the guest that it can only use
architectural events?  I see CPUID bits that enumerate which architectural events
are supported, but I'm not seeing anything that says _only_ architectural events
are supported.

> There is nothing wrong for the information provided by the kernel. I
> think it should be a KVM issue (my guess is the CPUID enumeration.) we
> should fix rather than simply disable the PMU for entire hybrid machines.

I'm not arguing this isn't KVM's problem, and I'm all for proper enabling in KVM,
but I'm not seeing any patches being posted.  In the meantime, we've got bug reports
coming in about KVM guests having PMU problems on hybrid hosts, and a pile of
evidence that strongly suggests this isn't going to be fixed by a one-line patch.

Again, I'm not against enabling vPMU on hybrid CPUs, but AFAICT the enabling is
non-trivial and may require new uAPI to provide the necessary information to
userspace.  As a short term fix, and something that can be backported to stable
trees, I don't see a better alternative than disabling vPMU support.

  reply	other threads:[~2023-01-20 17:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-20  0:40 [PATCH] perf/x86: KVM: Disable vPMU support on hybrid CPUs (host PMUs) Sean Christopherson
2023-01-20 14:39 ` Liang, Kan
2023-01-20 17:32   ` Sean Christopherson [this message]
2023-01-20 19:55     ` Liang, Kan
2023-01-20 20:34       ` Sean Christopherson
2023-01-20 22:00         ` Liang, Kan
2023-01-24  1:04           ` Andi Kleen
2023-01-24 15:31             ` Liang, Kan
2023-01-31 10:59               ` Peter Zijlstra

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=Y8rQJf3ki8a1aRjW@google.com \
    --to=seanjc@google.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jianfeng.gao@intel.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --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;
as well as URLs for NNTP newsgroup(s).