linux-kernel - Re: [RFC PATCH 1/4] perf: arm_pmuv3: Introduce module param to partition the PMU

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: <86bjvpvdn5.wl-maz@kernel.org>
Date: Wed, 29 Jan 2025 15:33:02 +0000
From: Marc Zyngier <maz@...nel.org>
To: Colton Lewis <coltonlewis@...gle.com>
Cc: kvm@...r.kernel.org,
	linux@...linux.org.uk,
	catalin.marinas@....com,
	will@...nel.org,
	oliver.upton@...ux.dev,
	joey.gouly@....com,
	suzuki.poulose@....com,
	yuzenghui@...wei.com,
	mark.rutland@....com,
	pbonzini@...hat.com,
	shuah@...nel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	kvmarm@...ts.linux.dev,
	linux-kselftest@...r.kernel.org
Subject: Re: [RFC PATCH 1/4] perf: arm_pmuv3: Introduce module param to partition the PMU

On Tue, 28 Jan 2025 22:08:27 +0000,
Colton Lewis <coltonlewis@...gle.com> wrote:
> 
> >> +	bitmap_set(cpu_pmu->cntr_mask, 0, pmcr_n);
> >> +
> >> +	if (reserved_guest_counters > 0 && reserved_guest_counters < pmcr_n) {
> >> +		cpu_pmu->hpmn = reserved_guest_counters;
> >> +		cpu_pmu->partitioned = true;
> 
> > Isn't this going to completely explode on a kernel running at EL1?
> 
> Trying to access an EL2 register at EL1 can do that. I'll add the
> appropriate hypercalls.

But what about a guest that would get passed the magic parameter? I
think you want to prevent that too.

> 
> > Also, how does it work in an asymmetric configuration where some CPUs
> > can satisfy the reservation, and some can't?
> 
> The CPUs that can't read their own value of PMCR.N below what the
> attempted reservation is and so do not get partitioned. Nothing changes
> for that CPU if it can't meet the reservation.

That's not what I meant. The question really is:

- do we want the reservation to be the number of counters reserved for
  the host

- or do we want it to be for the guest?

On symmetric systems, it doesn't matter. On broken big-little systems,
this changes everything (it has a direct impact on userspace's ability
to use the counters).

I think the design should reflect a decision on the above.

	M.

-- 
Without deviation from the norm, progress is not possible.