From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 0/5]
Date: Mon, 21 May 2018 19:19:49 +0100 [thread overview]
Message-ID: <20180521181948.GB19122@arm.com> (raw)
In-Reply-To: <20180518143913.26306-1-marc.zyngier@arm.com>
Hi Marc,
Thanks for this.
On Fri, May 18, 2018 at 03:39:08PM +0100, Marc Zyngier wrote:
> PMUv3 has been introduced with ARMv8 and, while it has only been used
> on 64bit systems so far, it would definitely be useful for 32bit
> guests running under KVM/arm64, for example.
>
> There is also the case of people natively running 32bit kernels on
> 64bit HW and trying to upstream unspeakable hacks, hoping that the
> stars will align and that they'll win the lottery (see [1]).
>
> So let's try again, and make the PMUv3 driver usable for everyone.
>
> This is done in three steps:
> (1) Move the driver from arch/arm64 to drivers/perf
> (2) Add a handful of system register accessors so that we can reuse
> the driver on 32bit
> (3) Provide the same accessors on 32bit, enable compilation, and
> make it the default selection for mach-virt.
>
> Tested on a Seattle box with 32bit guests.
I think we should go ahead with something like this, but I don't think
we're quite there with these patches. If we're going to move the arch code
out into drivers, let's do that for the perf_event* files under arch/arm/
as well. Then we could have a structure along the lines of:
drivers/perf/arm_pmu.c - As it is today
drivers/perf/arm_cpu/xscale_pmu.c - Only builds for 32-bit
drivers/perf/arm_cpu/armv6_pmu.c - Only builds for 32-bit
drivers/perf/arm_cpu/arch_pmu.c - Works for v7/v8 on
both 32-bit and 64-bit
The latter can then pull in whatever accessors it needs from the arch
code headers.
I know it's more of an invasive change, but this way we always end up
running the same code on the two architectures and it will be much easier
to maintain.
Will
next prev parent reply other threads:[~2018-05-21 18:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-18 14:39 [PATCH v3 0/5] Marc Zyngier
2018-05-18 14:39 ` [PATCH v3 1/5] arm64: perf: Move PMUv3 driver to drivers/perf Marc Zyngier
2018-05-18 14:39 ` [PATCH v3 2/5] arm64: perf: Abstract system register accesses away Marc Zyngier
2018-05-18 14:39 ` [PATCH v3 3/5] ARM: Make CONFIG_CPU_V7 valid for 32bit ARMv8 implementations Marc Zyngier
2018-05-18 14:39 ` [PATCH v3 4/5] ARM: perf: Allow the use of the PMUv3 driver on 32bit ARM Marc Zyngier
2018-05-21 9:34 ` Vladimir Murzin
2018-05-21 9:52 ` Marc Zyngier
2018-05-18 14:39 ` [PATCH v3 5/5] ARM: mach-virt: Select PMUv3 driver by default Marc Zyngier
2018-05-18 16:29 ` [PATCH v3 0/5] Vince Weaver
2018-05-18 16:41 ` Marc Zyngier
2018-05-18 17:39 ` Stefan Wahren
2018-05-21 18:19 ` Will Deacon [this message]
2021-12-19 23:46 ` Florian Fainelli
2021-12-20 8:59 ` Marc Zyngier
-- strict thread matches above, loose matches on Subject: below --
2023-05-29 15:35 Bernhard Rosenkränzer
2023-05-29 16:30 ` Matthias Brugger
2014-12-08 9:46 Yunzhi Li
2014-06-05 13:25 Maxime Ripard
2014-06-09 13:56 ` Linus Walleij
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=20180521181948.GB19122@arm.com \
--to=will.deacon@arm.com \
--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 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).