From: Oliver Upton <oliver.upton@linux.dev>
To: kvmarm@lists.linux.dev
Cc: Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Reiji Watanabe <reijiw@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Ravi Bangoria <ravi.bangoria@amd.com>,
Nathan Chancellor <nathan@kernel.org>,
mark.rutland@arm.com
Subject: Re: [PATCH 1/2] KVM: arm64: Iterate arm_pmus list to probe for default PMU
Date: Fri, 26 May 2023 08:41:21 +0000 [thread overview]
Message-ID: <ZHBwscC3aAq9KBB9@linux.dev> (raw)
In-Reply-To: <20230525212723.3361524-2-oliver.upton@linux.dev>
On Thu, May 25, 2023 at 09:27:21PM +0000, Oliver Upton wrote:
> To date KVM has relied on using a perf event to probe the core PMU at
> the time of vPMU initialization. Behind the scenes perf_event_init()
Oops:
s/perf_event_init/perf_init_event/
> would iteratively walk the PMUs of the system and return the PMU that
> could handle the event. However, an upcoming change in perf core will
> drop the iterative walk, thereby breaking the fragile dance we do on the
> KVM side.
>
> Avoid the problem altogether by iterating over the list of supported
> PMUs maintained in KVM, returning the core PMU that matches the CPU
> we were called on.
>
> Tested-by: Nathan Chancellor <nathan@kernel.org>
> Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
> ---
> arch/arm64/kvm/pmu-emul.c | 46 ++++++++++-----------------------------
> 1 file changed, 12 insertions(+), 34 deletions(-)
>
> diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
> index 45727d50d18d..5deddc49e745 100644
> --- a/arch/arm64/kvm/pmu-emul.c
> +++ b/arch/arm64/kvm/pmu-emul.c
> @@ -694,45 +694,23 @@ void kvm_host_pmu_init(struct arm_pmu *pmu)
>
> static struct arm_pmu *kvm_pmu_probe_armpmu(void)
> {
> - struct perf_event_attr attr = { };
> - struct perf_event *event;
> - struct arm_pmu *pmu = NULL;
> -
> - /*
> - * Create a dummy event that only counts user cycles. As we'll never
> - * leave this function with the event being live, it will never
> - * count anything. But it allows us to probe some of the PMU
> - * details. Yes, this is terrible.
> - */
> - attr.type = PERF_TYPE_RAW;
> - attr.size = sizeof(attr);
> - attr.pinned = 1;
> - attr.disabled = 0;
> - attr.exclude_user = 0;
> - attr.exclude_kernel = 1;
> - attr.exclude_hv = 1;
> - attr.exclude_host = 1;
> - attr.config = ARMV8_PMUV3_PERFCTR_CPU_CYCLES;
> - attr.sample_period = GENMASK(63, 0);
> + struct arm_pmu *tmp, *pmu = NULL;
> + struct arm_pmu_entry *entry;
> + int cpu;
>
> - event = perf_event_create_kernel_counter(&attr, -1, current,
> - kvm_pmu_perf_overflow, &attr);
> + mutex_lock(&arm_pmus_lock);
>
> - if (IS_ERR(event)) {
> - pr_err_once("kvm: pmu event creation failed %ld\n",
> - PTR_ERR(event));
> - return NULL;
> - }
> + cpu = smp_processor_id();
> + list_for_each_entry(entry, &arm_pmus, entry) {
> + tmp = entry->arm_pmu;
>
> - if (event->pmu) {
> - pmu = to_arm_pmu(event->pmu);
> - if (pmu->pmuver == ID_AA64DFR0_EL1_PMUVer_NI ||
> - pmu->pmuver == ID_AA64DFR0_EL1_PMUVer_IMP_DEF)
> - pmu = NULL;
> + if (cpumask_test_cpu(cpu, &tmp->supported_cpus)) {
> + pmu = tmp;
> + break;
> + }
> }
>
> - perf_event_disable(event);
> - perf_event_release_kernel(event);
> + mutex_unlock(&arm_pmus_lock);
>
> return pmu;
> }
> --
> 2.41.0.rc0.172.g3f132b7071-goog
>
--
Thanks,
Oliver
next prev parent reply other threads:[~2023-05-26 8:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-25 21:27 [PATCH 0/2] KVM: arm64: Fix for probing default PMU Oliver Upton
2023-05-25 21:27 ` [PATCH 1/2] KVM: arm64: Iterate arm_pmus list to probe for " Oliver Upton
2023-05-26 8:41 ` Oliver Upton [this message]
2023-05-25 21:27 ` [PATCH 2/2] KVM: arm64: Document default vPMU behavior on heterogeneous systems Oliver Upton
2023-05-31 9:49 ` [PATCH 0/2] KVM: arm64: Fix for probing default PMU 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=ZHBwscC3aAq9KBB9@linux.dev \
--to=oliver.upton@linux.dev \
--cc=james.morse@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=nathan@kernel.org \
--cc=peterz@infradead.org \
--cc=ravi.bangoria@amd.com \
--cc=reijiw@google.com \
--cc=suzuki.poulose@arm.com \
--cc=yuzenghui@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.