Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Vince Weaver <vincent.weaver@maine.edu>
Date:   Wed, 15 Jun 2022 13:57:03 -0400 (EDT)
To:     linux-kernel@vger.kernel.org
cc:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Jiri Olsa <jolsa@redhat.com>,
        Namhyung Kim <namhyung@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        linux-perf-users@vger.kernel.org, Will Deacon <will@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Rob Herring <robh@kernel.org>
Subject: [perf] why is /proc/sys/kernel/perf_user_access ARM64 only?
Message-ID: <30d95df2-c3b-b3e3-d65e-c6be0355fb1@maine.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk


Just wasted a lot of time tracking down why rdpmc() event reading wasn't 
working on an ARM64 machine.

It turns out ARM64 has added a custom
	"/proc/sys/kernel/perf_user_access"
to control rdpmc access, but only on ARM64.
	e2012600810c9ded81f6f63a8d04781be3c300ad

Why is this ARM64-only?  Why isn't this generic perf infrastructure?
How is this different from the existing
	/sys/bus/event_source/devices/cpu/rdpmc
tooling?

Also, when user events are disabled, why is the ARMv8 PMU not disabling
the cap_user_rdpmc bit in the perf mmap() page?

rdpmc was trouble before, but now it's an even bigger 
architecture-dependent mess just trying to figure out if the feature is 
enabled or not.

Vince