From: Peter Zijlstra <peterz@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Ingo Molnar <mingo@kernel.org>,
Dapeng Mi <dapeng1.mi@linux.intel.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Kan Liang <kan.liang@linux.intel.com>,
Like Xu <likexu@tencent.com>, Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
kvm@vger.kernel.org, linux-perf-users@vger.kernel.org,
linux-kernel@vger.kernel.org,
Zhenyu Wang <zhenyuw@linux.intel.com>,
Zhang Xiong <xiong.y.zhang@intel.com>,
Lv Zhiyuan <zhiyuan.lv@intel.com>,
Yang Weijiang <weijiang.yang@intel.com>,
Dapeng Mi <dapeng1.mi@intel.com>,
Jim Mattson <jmattson@google.com>,
David Dunn <daviddunn@google.com>,
Mingwei Zhang <mizhang@google.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Patch v4 07/13] perf/x86: Add constraint for guest perf metrics event
Date: Mon, 2 Oct 2023 22:40:17 +0200 [thread overview]
Message-ID: <20231002204017.GB27267@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <ZRroQg6flyGBtZTG@google.com>
On Mon, Oct 02, 2023 at 08:56:50AM -0700, Sean Christopherson wrote:
> On Mon, Oct 02, 2023, Ingo Molnar wrote:
> >
> > * Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > > On Fri, Sep 29, 2023 at 03:46:55PM +0000, Sean Christopherson wrote:
> > >
> > > > > I will firmly reject anything that takes the PMU away from the host
> > > > > entirely through.
> > > >
> > > > Why? What is so wrong with supporting use cases where the platform owner *wants*
> > > > to give up host PMU and NMI watchdog functionality? If disabling host PMU usage
> > > > were complex, highly invasive, and/or difficult to maintain, then I can understand
> > > > the pushback.
> > >
> > > Because it sucks.
> >
> > > You're forcing people to choose between no host PMU or a slow guest PMU.
>
> Nowhere did I say that we wouldn't take patches to improve the existing vPMU
> support.
Nowhere did I talk about vPMU -- I explicitly mentioned pass-through.
> > > worse it's not a choice based in technical reality.
>
> The technical reality is that context switching the PMU between host and guest
> requires reading and writing far too many MSRs for KVM to be able to context
> switch at every VM-Enter and every VM-Exit. And PMIs skidding past VM-Exit adds
> another layer of complexity to deal with.
I'm not sure what you're suggesting here. It will have to save/restore
all those MSRs anyway. Suppose it switches between vCPUs.
> > > It's a choice out of lazyness, disabling host PMU is not a requirement
> > > for pass-through.
>
> The requirement isn't passthrough access, the requirements are that the guest's
> PMU has accuracy that is on par with bare metal, and that exposing a PMU to the
> guest doesn't have a meaningful impact on guest performance.
Given you don't think that trapping MSR accesses is viable, what else
besides pass-through did you have in mind?
> > Not just a choice of laziness, but it will clearly be forced upon users
> > by external entities:
> >
> > "Pass ownership of the PMU to the guest and have no host PMU, or you
> > won't have sane guest PMU support at all. If you disagree, please open
> > a support ticket, which we'll ignore."
>
> We don't have sane guest PMU support today.
Because KVM is too damn hard to use, rebooting a machine is *sooo* much
easier -- and I'm really not kidding here.
Anyway, you want pass-through, but that doesn't mean host cannot use
PMU when vCPU thread is not running.
> If y'all are willing to let KVM redefined exclude_guest to be KVM's outer run
> loop, then I'm all for exploring that option. But that idea got shot down over
> a year ago[*].
I never saw that idea in that thread. You virt people keep talking like
I know how KVM works -- I'm not joking when I say I have no clue about
virt.
Sometimes I get a little clue after y'all keep bashing me over the head,
but it quickly erases itself.
> Or at least, that was my reading of things. Maybe it was just a
> misunderstanding because we didn't do a good job of defining the behavior.
This might be the case. I don't particularly care where the guest
boundary lies -- somewhere in the vCPU thread. Once the thread is gone,
PMU is usable again etc..
Re-reading parts of that linked thread, I see mention of
PT_MODE_HOST_GUEST -- see I knew we had something there, but I can never
remember all that nonsense. Worst part is that I can't find the relevant
perf code when I grep for that string :/
Anyway, what I don't like is KVM silently changing all events to
::exclude_guest=1. I would like all (pre-existing) ::exclude_guest=0
events to hard error when they run into a vCPU with pass-through on
(PERF_EVENT_STATE_ERROR). I would like event-creation to error out on
::exclude_guest=0 events when a vCPU with pass-through exists -- with
minimal scope (this probably means all CPU events, but only relevant
vCPU events).
It also means ::exclude_guest should actually work -- it often does not
today -- the IBS thing for example totally ignores it.
Anyway, none of this means host cannot use PMU because virt muck wants
it.
next prev parent reply other threads:[~2023-10-02 20:41 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-27 3:31 [Patch v4 00/13] Enable fixed counter 3 and topdown perf metrics for vPMU Dapeng Mi
2023-09-27 3:31 ` [Patch v4 01/13] KVM: x86/pmu: Add Intel CPUID-hinted TopDown slots event Dapeng Mi
2023-09-27 3:31 ` [Patch v4 02/13] KVM: x86/pmu: Support PMU fixed counter 3 Dapeng Mi
2023-09-27 3:31 ` [Patch v4 03/13] perf/core: Add function perf_event_group_leader_check() Dapeng Mi
2023-09-27 3:31 ` [Patch v4 04/13] perf/core: Add function perf_event_move_group() Dapeng Mi
2023-09-27 3:31 ` [Patch v4 05/13] perf/core: Add *group_leader for perf_event_create_group_kernel_counters() Dapeng Mi
2023-09-27 3:31 ` [Patch v4 06/13] perf/x86: Fix typos and inconsistent indents in perf_event header Dapeng Mi
2023-09-27 3:31 ` [Patch v4 07/13] perf/x86: Add constraint for guest perf metrics event Dapeng Mi
2023-09-27 11:33 ` Peter Zijlstra
2023-09-27 17:27 ` Sean Christopherson
2023-09-28 9:24 ` Mi, Dapeng
2023-09-29 11:53 ` Peter Zijlstra
2023-09-29 15:20 ` Ravi Bangoria
2023-10-02 12:29 ` Peter Zijlstra
2023-10-03 6:36 ` Ravi Bangoria
2023-09-29 15:46 ` Sean Christopherson
2023-09-30 3:29 ` Jim Mattson
2023-10-01 0:31 ` Namhyung Kim
2023-10-02 11:57 ` Peter Zijlstra
2023-10-02 13:30 ` Ingo Molnar
2023-10-02 15:23 ` David Dunn
2023-10-02 19:02 ` Mingwei Zhang
2023-10-02 15:56 ` Sean Christopherson
2023-10-02 19:50 ` Liang, Kan
2023-10-02 20:52 ` Peter Zijlstra
2023-10-02 20:40 ` Peter Zijlstra [this message]
2023-10-03 0:56 ` Sean Christopherson
2023-10-03 8:16 ` Peter Zijlstra
2023-10-03 15:23 ` Sean Christopherson
2023-10-03 18:21 ` Jim Mattson
2023-10-04 11:32 ` Peter Zijlstra
2023-10-04 11:21 ` Peter Zijlstra
2023-10-04 19:51 ` Mingwei Zhang
2023-10-04 21:50 ` Sean Christopherson
2023-10-04 22:05 ` Sean Christopherson
2023-10-08 10:04 ` Like Xu
2023-10-09 17:03 ` Manali Shukla
2023-10-11 14:15 ` Peter Zijlstra
2023-10-17 10:24 ` Manali Shukla
2023-10-17 16:58 ` Mingwei Zhang
2023-10-18 0:01 ` Mingwei Zhang
2023-10-11 14:20 ` Peter Zijlstra
2023-10-13 17:02 ` Sean Christopherson
2023-10-03 17:31 ` Manali Shukla
2023-10-03 22:02 ` Mingwei Zhang
2023-10-04 20:43 ` Sean Christopherson
2023-09-27 3:31 ` [Patch v4 08/13] perf/core: Add new function perf_event_topdown_metrics() Dapeng Mi
2023-09-27 3:31 ` [Patch v4 09/13] perf/x86/intel: Handle KVM virtual metrics event in perf system Dapeng Mi
2023-09-27 3:31 ` [Patch v4 10/13] KVM: x86/pmu: Extend pmc_reprogram_counter() to create group events Dapeng Mi
2023-09-27 3:31 ` [Patch v4 11/13] KVM: x86/pmu: Support topdown perf metrics feature Dapeng Mi
2023-09-27 3:31 ` [Patch v4 12/13] KVM: x86/pmu: Handle PERF_METRICS overflow Dapeng Mi
2023-09-27 3:31 ` [Patch v4 13/13] KVM: x86/pmu: Expose Topdown in MSR_IA32_PERF_CAPABILITIES Dapeng Mi
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=20231002204017.GB27267@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=dapeng1.mi@intel.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=daviddunn@google.com \
--cc=irogers@google.com \
--cc=jmattson@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=likexu@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=mizhang@google.com \
--cc=namhyung@kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=weijiang.yang@intel.com \
--cc=xiong.y.zhang@intel.com \
--cc=zhenyuw@linux.intel.com \
--cc=zhiyuan.lv@intel.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 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).