All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Keqian Zhu <zhukeqian1@huawei.com>
Cc: linux-s390@vger.kernel.org, Rich Felker <dalias@libc.org>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	kvm@vger.kernel.org, linux-sh@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Heiko Carstens <hca@linux.ibm.com>,
	linux-kernel@vger.kernel.org,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	nathan@kernel.org, Christian Borntraeger <borntraeger@de.ibm.com>,
	Will Deacon <will@kernel.org>,
	kernel-team@android.com, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/5] KVM: arm64: Divorce the perf code from oprofile helpers
Date: Thu, 15 Apr 2021 14:49:30 +0100	[thread overview]
Message-ID: <87czuvmzdh.wl-maz@kernel.org> (raw)
In-Reply-To: <da73e0c7-4dd7-ce69-3304-3da8f1521127@huawei.com>

On Thu, 15 Apr 2021 12:34:40 +0100,
Keqian Zhu <zhukeqian1@huawei.com> wrote:
> 
> Hi Marc,
> 
> On 2021/4/15 18:42, Marc Zyngier wrote:
> > On Thu, 15 Apr 2021 07:59:26 +0100,
> > Keqian Zhu <zhukeqian1@huawei.com> wrote:
> >>
> >> Hi Marc,
> >>
> >> On 2021/4/14 21:44, Marc Zyngier wrote:
> >>> KVM/arm64 is the sole user of perf_num_counters(), and really
> >>> could do without it. Stop using the obsolete API by relying on
> >>> the existing probing code.
> >>>
> >>> Signed-off-by: Marc Zyngier <maz@kernel.org>
> >>> ---
> >>>  arch/arm64/kvm/perf.c     | 7 +------
> >>>  arch/arm64/kvm/pmu-emul.c | 2 +-
> >>>  include/kvm/arm_pmu.h     | 4 ++++
> >>>  3 files changed, 6 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/kvm/perf.c b/arch/arm64/kvm/perf.c
> >>> index 739164324afe..b8b398670ef2 100644
> >>> --- a/arch/arm64/kvm/perf.c
> >>> +++ b/arch/arm64/kvm/perf.c
> >>> @@ -50,12 +50,7 @@ static struct perf_guest_info_callbacks kvm_guest_cbs = {
> >>>  
> >>>  int kvm_perf_init(void)
> >>>  {
> >>> -	/*
> >>> -	 * Check if HW_PERF_EVENTS are supported by checking the number of
> >>> -	 * hardware performance counters. This could ensure the presence of
> >>> -	 * a physical PMU and CONFIG_PERF_EVENT is selected.
> >>> -	 */
> >>> -	if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0)
> >>> +	if (kvm_pmu_probe_pmuver() != 0xf)
> >> The probe() function may be called many times
> >> (kvm_arm_pmu_v3_set_attr also calls it).  I don't know whether the
> >> first calling is enough. If so, can we use a static variable in it,
> >> so the following calling can return the result right away?
> > 
> > No, because that wouldn't help with crappy big-little implementations
> > that could have PMUs with different versions. We want to find the
> > version at the point where the virtual PMU is created, which is why we
> > call the probe function once per vcpu.
> I see.
> 
> But AFAICS the pmuver is placed in kvm->arch, and the probe function is called
> once per VM. Maybe I miss something.

You're right, I mis-remembered. This doesn't change much though.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Keqian Zhu <zhukeqian1@huawei.com>
Cc: <kvm@vger.kernel.org>, <kvmarm@lists.cs.columbia.edu>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <linux-s390@vger.kernel.org>,
	<linux-sh@vger.kernel.org>, Rich Felker <dalias@libc.org>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	"Peter\ Zijlstra" <peterz@infradead.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Heiko Carstens <hca@linux.ibm.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>, <nathan@kernel.org>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	<kernel-team@android.com>, Will Deacon <will@kernel.org>
Subject: Re: [PATCH 1/5] KVM: arm64: Divorce the perf code from oprofile helpers
Date: Thu, 15 Apr 2021 14:49:30 +0100	[thread overview]
Message-ID: <87czuvmzdh.wl-maz@kernel.org> (raw)
In-Reply-To: <da73e0c7-4dd7-ce69-3304-3da8f1521127@huawei.com>

On Thu, 15 Apr 2021 12:34:40 +0100,
Keqian Zhu <zhukeqian1@huawei.com> wrote:
> 
> Hi Marc,
> 
> On 2021/4/15 18:42, Marc Zyngier wrote:
> > On Thu, 15 Apr 2021 07:59:26 +0100,
> > Keqian Zhu <zhukeqian1@huawei.com> wrote:
> >>
> >> Hi Marc,
> >>
> >> On 2021/4/14 21:44, Marc Zyngier wrote:
> >>> KVM/arm64 is the sole user of perf_num_counters(), and really
> >>> could do without it. Stop using the obsolete API by relying on
> >>> the existing probing code.
> >>>
> >>> Signed-off-by: Marc Zyngier <maz@kernel.org>
> >>> ---
> >>>  arch/arm64/kvm/perf.c     | 7 +------
> >>>  arch/arm64/kvm/pmu-emul.c | 2 +-
> >>>  include/kvm/arm_pmu.h     | 4 ++++
> >>>  3 files changed, 6 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/kvm/perf.c b/arch/arm64/kvm/perf.c
> >>> index 739164324afe..b8b398670ef2 100644
> >>> --- a/arch/arm64/kvm/perf.c
> >>> +++ b/arch/arm64/kvm/perf.c
> >>> @@ -50,12 +50,7 @@ static struct perf_guest_info_callbacks kvm_guest_cbs = {
> >>>  
> >>>  int kvm_perf_init(void)
> >>>  {
> >>> -	/*
> >>> -	 * Check if HW_PERF_EVENTS are supported by checking the number of
> >>> -	 * hardware performance counters. This could ensure the presence of
> >>> -	 * a physical PMU and CONFIG_PERF_EVENT is selected.
> >>> -	 */
> >>> -	if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0)
> >>> +	if (kvm_pmu_probe_pmuver() != 0xf)
> >> The probe() function may be called many times
> >> (kvm_arm_pmu_v3_set_attr also calls it).  I don't know whether the
> >> first calling is enough. If so, can we use a static variable in it,
> >> so the following calling can return the result right away?
> > 
> > No, because that wouldn't help with crappy big-little implementations
> > that could have PMUs with different versions. We want to find the
> > version at the point where the virtual PMU is created, which is why we
> > call the probe function once per vcpu.
> I see.
> 
> But AFAICS the pmuver is placed in kvm->arch, and the probe function is called
> once per VM. Maybe I miss something.

You're right, I mis-remembered. This doesn't change much though.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-04-15 13:49 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14 13:44 [PATCH 0/5] perf: oprofile spring cleanup Marc Zyngier
2021-04-14 13:44 ` Marc Zyngier
2021-04-14 13:44 ` Marc Zyngier
2021-04-14 13:44 ` [PATCH 1/5] KVM: arm64: Divorce the perf code from oprofile helpers Marc Zyngier
2021-04-14 13:44   ` Marc Zyngier
2021-04-14 13:44   ` Marc Zyngier
2021-04-15  6:59   ` Keqian Zhu
2021-04-15  6:59     ` Keqian Zhu
2021-04-15  6:59     ` Keqian Zhu
2021-04-15 10:42     ` Marc Zyngier
2021-04-15 10:42       ` Marc Zyngier
2021-04-15 11:34       ` Keqian Zhu
2021-04-15 11:34         ` Keqian Zhu
2021-04-15 11:34         ` Keqian Zhu
2021-04-15 13:49         ` Marc Zyngier [this message]
2021-04-15 13:49           ` Marc Zyngier
2021-04-22 10:43   ` Will Deacon
2021-04-22 10:43     ` Will Deacon
2021-04-22 10:43     ` Will Deacon
2021-04-14 13:44 ` [PATCH 2/5] arm64: Get rid of oprofile leftovers Marc Zyngier
2021-04-14 13:44   ` Marc Zyngier
2021-04-14 13:44   ` Marc Zyngier
2021-04-22 10:45   ` Will Deacon
2021-04-22 10:45     ` Will Deacon
2021-04-22 10:45     ` Will Deacon
2021-04-14 13:44 ` [PATCH 3/5] s390: " Marc Zyngier
2021-04-14 13:44   ` Marc Zyngier
2021-04-14 13:44   ` Marc Zyngier
2021-04-15 10:38   ` Heiko Carstens
2021-04-15 10:38     ` Heiko Carstens
2021-04-15 10:38     ` Heiko Carstens
2021-04-15 10:47     ` Marc Zyngier
2021-04-15 10:47       ` Marc Zyngier
2021-04-15 10:47       ` Marc Zyngier
2021-04-15 12:12       ` Heiko Carstens
2021-04-15 12:12         ` Heiko Carstens
2021-04-15 12:12         ` Heiko Carstens
2021-04-14 13:44 ` [PATCH 4/5] sh: " Marc Zyngier
2021-04-14 13:44   ` Marc Zyngier
2021-04-14 13:44   ` Marc Zyngier
2021-04-14 19:09   ` Geert Uytterhoeven
2021-04-14 19:09     ` Geert Uytterhoeven
2021-04-14 19:09     ` Geert Uytterhoeven
2021-04-14 13:44 ` [PATCH 5/5] perf: " Marc Zyngier
2021-04-14 13:44   ` Marc Zyngier
2021-04-14 13:44   ` Marc Zyngier
2021-04-22 10:47   ` Will Deacon
2021-04-22 10:47     ` Will Deacon
2021-04-22 10:47     ` Will Deacon
2021-04-22 12:48 ` [PATCH 0/5] perf: oprofile spring cleanup Marc Zyngier
2021-04-22 12:48   ` Marc Zyngier
2021-04-22 12:48   ` Marc Zyngier

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=87czuvmzdh.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=acme@kernel.org \
    --cc=borntraeger@de.ibm.com \
    --cc=dalias@libc.org \
    --cc=hca@linux.ibm.com \
    --cc=kernel-team@android.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=peterz@infradead.org \
    --cc=viresh.kumar@linaro.org \
    --cc=will@kernel.org \
    --cc=ysato@users.sourceforge.jp \
    --cc=zhukeqian1@huawei.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.