linux-kernel - Re: [PATCH v6 02/10] arm64: perf: Enable PMU counter direct access for perf event

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9e904f20-7943-ee44-9653-7aa949c3ba88@arm.com>
Date:   Tue, 30 Mar 2021 12:30:58 +0100
From:   Zachary Leaf <zachary.leaf@....com>
To:     Rob Herring <robh@...nel.org>, Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jiri Olsa <jolsa@...hat.com>,
        Mark Rutland <mark.rutland@....com>
Cc:     Ian Rogers <irogers@...gle.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        honnappa.nagarahalli@....com,
        Raphael Gault <raphael.gault@....com>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Itaru Kitayama <itaru.kitayama@...il.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        nd@....com
Subject: Re: [PATCH v6 02/10] arm64: perf: Enable PMU counter direct access
 for perf event

On 11/03/2021 00:08, Rob Herring wrote:
> 
> In order to enable 64-bit counters for userspace when available, a new
> config1 bit is added for userspace to indicate it wants userspace counter
> access. This bit allows the kernel to decide if chaining should be
> disabled and chaining and userspace access are incompatible.
> The modes for config1 are as follows:
> 
> config1 = 0 or 2 : user access enabled and always 32-bit
> config1 = 1 : user access disabled and always 64-bit (using chaining if needed)
> config1 = 3 : user access enabled and counter size matches underlying counter.
> 

Thanks for this Rob. That makes it extremely easy to request 64 bit
userspace counters without having to worry about the underlying bit
width supported on your system.

The underlying PMUv3 bit width is otherwise not accessible from
userspace as far as I can tell (e.g. the relevant PMUVer bits [11:8] of
ID_AA64DFR0_EL1 are masked off when reading from EL0 [1]), and the
workaround of requesting 64 bit, checking cap_user_rdpmc for userspace
access, and retrying with 32 bit was not that user friendly. I think it
makes a lot of sense for the kernel to handle/expose it here rather than
handled in the application code.

I think it's worth mentioning here if anyone searches, is that the 32
bit counter behaviour when added to the perf_event_mmap_page->offset is
effectively the same as a single 64 bit counter due to the offset being
incremented on overflow. Using a true 64 bit counter can avoid the
overhead of handling an interrupt for each overflow (and obviously has a
lot more headroom before it overflows, if you require very long running
perf stats).

I have tested the new config1 flags on N1-SDP and the behaviour is as
expected.

[1]
https://github.com/torvalds/linux/blob/master/Documentation/arm64/cpu-feature-registers.rst