From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: kvmarm@lists.linux.dev, Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Mingwei Zhang <mizhang@google.com>,
Colton Lewis <coltonlewis@google.com>,
Raghavendra Rao Ananta <rananta@google.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 05/14] KVM: arm64: Always allow fixed cycle counter
Date: Wed, 04 Dec 2024 09:04:26 +0000 [thread overview]
Message-ID: <87ikrzstt1.wl-maz@kernel.org> (raw)
In-Reply-To: <Z0-HBsBgf6WB7x4R@linux.dev>
On Tue, 03 Dec 2024 22:32:38 +0000,
Oliver Upton <oliver.upton@linux.dev> wrote:
>
> On Tue, Dec 03, 2024 at 09:32:10PM +0000, Marc Zyngier wrote:
> > On Tue, 03 Dec 2024 19:32:11 +0000,
> > Oliver Upton <oliver.upton@linux.dev> wrote:
> > >
> > > The fixed CPU cycle counter is mandatory for PMUv3, so it doesn't make a
> > > lot of sense allowing userspace to filter it. Only apply the PMU event
> > > filter to *programmed* event counters.
> >
> > But that's a change in ABI, isn't it? We explicitly say in the
> > documentation that the cycle counter can be filtered by specifying
> > event 0x11.
>
> Yeah... A bit of a dirty shortcut I took because I don't like the ABI,
> but distaste isn't enough to break it :)
>
> > More importantly, the current filtering works in terms of events, and
> > not in terms of counters.
> >
> > Instead of changing the ABI, how about simply not supporting filtering
> > on such non-compliant HW? Surely that would simplify a few things.
>
> Yeah, that sounds reasonable. Especially if we allow programmable event
> counters where the event ID space doesn't match the architecture.
Another thing I have been wondering is if a slightly better approach
would be to move some of the handling to the PMU driver itself, and
let it emulate PMUv3 if it can. This would allow conversion of event
numbers in situ rather than polluting the PMUv3 code in KVM.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-12-04 9:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-03 19:32 [RFC PATCH 00/14] KVM: arm64: Support FEAT_PMUv3 on Apple hardware Oliver Upton
2024-12-03 19:32 ` [RFC PATCH 01/14] drivers/perf: apple_m1: Refactor event select/filter configuration Oliver Upton
2024-12-03 19:32 ` [RFC PATCH 02/14] drivers/perf: apple_m1: Support host/guest event filtering Oliver Upton
2024-12-03 19:32 ` [RFC PATCH 03/14] drivers/perf: apple_m1: Map generic branch events Oliver Upton
2024-12-03 19:32 ` [RFC PATCH 04/14] KVM: arm64: Compute PMCEID from arm_pmu's event bitmaps Oliver Upton
2024-12-03 19:32 ` [RFC PATCH 05/14] KVM: arm64: Always allow fixed cycle counter Oliver Upton
2024-12-03 21:32 ` Marc Zyngier
2024-12-03 22:32 ` Oliver Upton
2024-12-04 9:04 ` Marc Zyngier [this message]
2024-12-04 21:56 ` Oliver Upton
2024-12-10 9:49 ` Marc Zyngier
2024-12-03 19:32 ` [RFC PATCH 06/14] KVM: arm64: Use PERF_COUNT_HW_CPU_CYCLES for " Oliver Upton
2024-12-03 19:32 ` [RFC PATCH 07/14] KVM: arm64: Use a cpucap to determine if system supports FEAT_PMUv3 Oliver Upton
2024-12-03 19:32 ` [RFC PATCH 08/14] KVM: arm64: Drop kvm_arm_pmu_available static key Oliver Upton
2024-12-03 19:32 ` [RFC PATCH 09/14] KVM: arm64: Use guard() to cleanup usage of arm_pmus_lock Oliver Upton
2024-12-03 19:32 ` [RFC PATCH 10/14] KVM: arm64: Move PMUVer filtering into KVM code Oliver Upton
2024-12-03 19:32 ` [RFC PATCH 11/14] KVM: arm64: Compute synthetic sysreg ESR for Apple PMUv3 traps Oliver Upton
2024-12-03 19:32 ` [RFC PATCH 12/14] KVM: arm64: Advertise PMUv3 if IMPDEF traps are present Oliver Upton
2024-12-03 19:32 ` [RFC PATCH 13/14] KVM: arm64: Advertise 0 event counters for IMPDEF PMU Oliver Upton
2024-12-03 19:34 ` [RFC PATCH 14/14] arm64: Enable IMP DEF PMUv3 traps on Apple M2 Oliver Upton
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=87ikrzstt1.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=coltonlewis@google.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mizhang@google.com \
--cc=oliver.upton@linux.dev \
--cc=rananta@google.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--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 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).