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

[Marc Zyngier]

On Tue, 28 Jan 2025 22:08:27 +0000,
Colton Lewis <coltonlewis@xxxxxxxxxx> 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.