From: Marc Zyngier <maz@kernel.org>
To: Andre Przywara <andre.przywara@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, kernel-team@android.com,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH 1/2] KVM: arm64: Turn kvm_arm_support_pmu_v3() into a static key
Date: Thu, 28 Jan 2021 16:56:01 +0000 [thread overview]
Message-ID: <9bf9be4149cfd0671fe5178ce553159b@kernel.org> (raw)
In-Reply-To: <20210128151643.6e2c3668@slackpad.fritz.box>
On 2021-01-28 15:16, Andre Przywara wrote:
> On Tue, 26 Jan 2021 15:15:20 +0000
> Marc Zyngier <maz@kernel.org> wrote:
>
> Hi Marc,
>
>> We currently find out about the presence of a HW PMU (or the handling
>> of that PMU by perf, which amounts to the same thing) in a fairly
>> roundabout way, by checking the number of counters available to perf.
>> That's good enough for now, but we will soon need to find about about
>> that on paths where perf is out of reach (in the world switch).
>>
>> Instead, let's turn kvm_arm_support_pmu_v3() into a static key.
>
> I am sure the pesky build bot has told you about it already, but this
> fails when ARM_PMU is not defined, as perf_num_counters() is not
> defined. It's bit nasty, since it's a generic function, so we
> can't easily stub it in its original header.
No sign from the bot yet, but that's indeed a problem. Well spotted.
> Shall we find a place somewhere in arch/arm64 and provide a stub
> implementation there, #ifndef CONFIG_ARM_PMU? Sounds ugly, though.
>
> Or something else entirely?
How about:
diff --git a/arch/arm64/kvm/perf.c b/arch/arm64/kvm/perf.c
index 198fa4266b2d..739164324afe 100644
--- a/arch/arm64/kvm/perf.c
+++ b/arch/arm64/kvm/perf.c
@@ -55,7 +55,7 @@ int kvm_perf_init(void)
* hardware performance counters. This could ensure the presence of
* a physical PMU and CONFIG_PERF_EVENT is selected.
*/
- if (perf_num_counters() > 0)
+ if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0)
static_branch_enable(&kvm_arm_pmu_available);
return perf_register_guest_info_callbacks(&kvm_guest_cbs);
It certainly compiles here.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
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: Andre Przywara <andre.przywara@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>,
James Morse <james.morse@arm.com>,
linux-arm-kernel@lists.infradead.org, kernel-team@android.com,
kvmarm@lists.cs.columbia.edu,
Julien Thierry <julien.thierry.kdev@gmail.com>
Subject: Re: [PATCH 1/2] KVM: arm64: Turn kvm_arm_support_pmu_v3() into a static key
Date: Thu, 28 Jan 2021 16:56:01 +0000 [thread overview]
Message-ID: <9bf9be4149cfd0671fe5178ce553159b@kernel.org> (raw)
In-Reply-To: <20210128151643.6e2c3668@slackpad.fritz.box>
On 2021-01-28 15:16, Andre Przywara wrote:
> On Tue, 26 Jan 2021 15:15:20 +0000
> Marc Zyngier <maz@kernel.org> wrote:
>
> Hi Marc,
>
>> We currently find out about the presence of a HW PMU (or the handling
>> of that PMU by perf, which amounts to the same thing) in a fairly
>> roundabout way, by checking the number of counters available to perf.
>> That's good enough for now, but we will soon need to find about about
>> that on paths where perf is out of reach (in the world switch).
>>
>> Instead, let's turn kvm_arm_support_pmu_v3() into a static key.
>
> I am sure the pesky build bot has told you about it already, but this
> fails when ARM_PMU is not defined, as perf_num_counters() is not
> defined. It's bit nasty, since it's a generic function, so we
> can't easily stub it in its original header.
No sign from the bot yet, but that's indeed a problem. Well spotted.
> Shall we find a place somewhere in arch/arm64 and provide a stub
> implementation there, #ifndef CONFIG_ARM_PMU? Sounds ugly, though.
>
> Or something else entirely?
How about:
diff --git a/arch/arm64/kvm/perf.c b/arch/arm64/kvm/perf.c
index 198fa4266b2d..739164324afe 100644
--- a/arch/arm64/kvm/perf.c
+++ b/arch/arm64/kvm/perf.c
@@ -55,7 +55,7 @@ int kvm_perf_init(void)
* hardware performance counters. This could ensure the presence of
* a physical PMU and CONFIG_PERF_EVENT is selected.
*/
- if (perf_num_counters() > 0)
+ if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0)
static_branch_enable(&kvm_arm_pmu_available);
return perf_register_guest_info_callbacks(&kvm_guest_cbs);
It certainly compiles here.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-01-28 16:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-26 15:15 [PATCH 0/2] KVM: arm64: Prevent spurious PMU accesses when no Marc Zyngier
2021-01-26 15:15 ` Marc Zyngier
2021-01-26 15:15 ` [PATCH 1/2] KVM: arm64: Turn kvm_arm_support_pmu_v3() into a static key Marc Zyngier
2021-01-26 15:15 ` Marc Zyngier
2021-01-28 15:16 ` Andre Przywara
2021-01-28 15:16 ` Andre Przywara
2021-01-28 16:56 ` Marc Zyngier [this message]
2021-01-28 16:56 ` Marc Zyngier
2021-01-28 18:42 ` Andre Przywara
2021-01-28 18:42 ` Andre Przywara
2021-01-26 15:15 ` [PATCH 2/2] KVM: arm64: Don't access PMSELR_EL0/PMUSERENR_EL0 when no PMU is available Marc Zyngier
2021-01-26 15:15 ` 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=9bf9be4149cfd0671fe5178ce553159b@kernel.org \
--to=maz@kernel.org \
--cc=andre.przywara@arm.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.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 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.