Marc Zyngier maz@kernel.org writes:
On Tue, 28 Jan 2025 22:08:27 +0000, Colton Lewis coltonlewis@google.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.
That doesn't matter because the ARM manual states that when HPMN is set, reads of PMCR.N from EL1 have that value and I've made sure in the second patch KVM does that, so a guest believes it has a system where reserved_guest_counters/HPMN == PMCR.N so there is no partition.
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.
As currently written and reflected in the name reserved_guest_counters this series is making a reservation for the guest.
After talking with Oliver it probably makes more sense to make a reservation for the host. This is closer to the semantics of the underlying CPU feature.
In the limit case it's impossible to leave the host without counters. All valid values for HPMN leave the host at least 1, but should we make any guarantees beyond that?