From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/16] arm/arm64: Workaround misprogrammed CNTFRQ
Date: Mon, 24 Jul 2017 14:12:53 +0100 [thread overview]
Message-ID: <20170724131252.GG29919@arm.com> (raw)
In-Reply-To: <c3c34b9b-3872-bbb1-28cf-07aa6c739e94@arm.com>
On Mon, Jul 24, 2017 at 01:48:37PM +0100, Marc Zyngier wrote:
> On 24/07/17 13:19, Will Deacon wrote:
> > On Fri, Jul 21, 2017 at 06:15:26PM +0100, Marc Zyngier wrote:
> >> It is an unfortunate situation that CNTFRQ{,_EL0} is often
> >> misprogrammed from the firmware side, leaving it up to the kernel to
> >> work around it. This is usually done by providing an alternative
> >> frequency in the Device Tree.
> >>
> >> Unfortunately, CNTFRQ is accessible from EL0, giving userspace the
> >> wrong frequency, and potentially a different frequency per CPU, which
> >> is definitely not what you want. A possible workaround is to trap this
> >> into the kernel and to emulate it (together with the VDSO being
> >> disabled), and this is what this series is achieving.
> >
> > Which userspace is actually affected by a broken CNTFRQ register? I suspect
> > most users will be more upset at losing their (perfectly functional) vDSO
> > acceleration than they are about having a broken CNTFRQ value that is hardly
> > ever used, especially since this affects quite a few systems.
>
> OpenMPI is one of the things I'm aware of (we broke it when implementing
> the first set of timer workarounds), and from trawling the Debian code
> search, at least HHVM is another candidate. How this will affect them is
> anybody's guess.
The latest mcrouter sources pulled into HHVM don't use cntfrq, but you're
right about OpenMPI. However, these things are using the counter directly
as a performance optimisation: the moment we start trapping then they've
lost. I doubt it's much better than giving the wrong data for the
frequency (i.e. they're just as broken in both cases).
So, if they want to run on these systems, their best bet is to use the
vDSO-accelerated clock_gettime implementation. Yes, there's a dispatch cost
compared to an inline asm, but it will beat the pants off a trap to the
kernel. The problem is that this patch series prevents them from doing that
and just means they're screwed whatever they do. We can point at the broken
firmware, but it doesn't feel to me like this workaround is really helping
anybody :/.
Will
next prev parent reply other threads:[~2017-07-24 13:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-21 17:15 [PATCH 00/16] arm/arm64: Workaround misprogrammed CNTFRQ Marc Zyngier
2017-07-21 17:15 ` [PATCH 01/16] arm64: Use arch_timer_get_rate when trapping CNTFRQ_EL0 Marc Zyngier
2017-07-21 17:15 ` [PATCH 02/16] arm64: Add decoding macros for CP15_32 and CP15_64 traps Marc Zyngier
2017-07-21 17:15 ` [PATCH 03/16] arm64: compat: Add separate CP15 trapping hook Marc Zyngier
2017-07-21 17:15 ` [PATCH 04/16] arm64: compat: Add condition code checks and IT advance Marc Zyngier
2017-07-21 17:15 ` [PATCH 05/16] arm64: compat: Add cp15_32 and cp15_64 handler arrays Marc Zyngier
2017-07-21 17:15 ` [PATCH 06/16] arm64: compat: Add CNTVCT trap handler Marc Zyngier
2017-07-21 17:15 ` [PATCH 07/16] arm64: compat: Add CNTFRQ " Marc Zyngier
2017-07-21 17:15 ` [PATCH 08/16] ARM: Let arm_check_condition work with Thumb Marc Zyngier
2017-07-21 17:15 ` [PATCH 09/16] ARM: Check condition code before trying to handle an UNDEF Marc Zyngier
2017-07-21 17:15 ` [PATCH 10/16] ARM: Add arm_advance_itstate helper Marc Zyngier
2017-07-21 17:15 ` [PATCH 11/16] ARM: Advance the IT state on successful emulation of an UNDEF Marc Zyngier
2017-07-21 17:15 ` [PATCH 12/16] ARM: Simplify condition checks in swp_handler Marc Zyngier
2017-07-21 17:15 ` [PATCH 13/16] ARM: Handle trapping of CNTVCT from userspace Marc Zyngier
2017-07-21 17:15 ` [PATCH 14/16] ARM: Handle trapping of CNTFRQ " Marc Zyngier
2017-07-21 17:15 ` [PATCH 15/16] clocksource/arm_arch_timer: Add helper to disable VDSO fastpath Marc Zyngier
2017-07-21 17:15 ` [PATCH 16/16] clocksource/arm_arch_timer: Trap user access to CNT{VCT, FRQ} if CNTFRQ is invalid Marc Zyngier
2017-07-24 12:19 ` [PATCH 00/16] arm/arm64: Workaround misprogrammed CNTFRQ Will Deacon
2017-07-24 12:48 ` Marc Zyngier
2017-07-24 13:12 ` Will Deacon [this message]
2017-07-24 13:35 ` Marc Zyngier
2017-07-25 11:46 ` Will Deacon
-- strict thread matches above, loose matches on Subject: below --
2017-07-21 17:14 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=20170724131252.GG29919@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).