Re: [PATCH v5 16/24] KVM: arm64: Account for partitioning in PMCR_EL0 access

Colton Lewis
2025-12-12T21:31:47Z

Oliver Upton <oupton@kernel.org> writes:

> On Tue, Dec 09, 2025 at 08:51:13PM +0000, Colton Lewis wrote:
>> Make sure reads and writes to PMCR_EL0 conform to additional
>> constraints imposed when the PMU is partitioned.

>> Signed-off-by: Colton Lewis <coltonlewis@google.com>
>> ---
>> arch/arm64/kvm/pmu.c | 2 +-
>> arch/arm64/kvm/sys_regs.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)

>> diff --git a/arch/arm64/kvm/pmu.c b/arch/arm64/kvm/pmu.c
>> index 1fd012f8ff4a9..48b39f096fa12 100644
>> --- a/arch/arm64/kvm/pmu.c
>> +++ b/arch/arm64/kvm/pmu.c
>> @@ -877,7 +877,7 @@ u64 kvm_pmu_accessible_counter_mask(struct kvm_vcpu
>> *vcpu)
>> u64 kvm_vcpu_read_pmcr(struct kvm_vcpu *vcpu)
>> {
>> u64 pmcr = __vcpu_sys_reg(vcpu, PMCR_EL0);
>> - u64 n = vcpu->kvm->arch.nr_pmu_counters;
>> + u64 n = kvm_pmu_guest_num_counters(vcpu);

> Why can't the value of vcpu->kvm->arch.nr_pmu_counters be trusted?

Similar to discussion on a previous patch, I need to move some
validation to the ioctl where it's set.

>> @@ -1360,7 +1360,7 @@ static int set_pmcr(struct kvm_vcpu *vcpu, const
>> struct sys_reg_desc *r,
>> */
>> if (!kvm_vm_has_ran_once(kvm) &&
>> !vcpu_has_nv(vcpu) &&
>> - new_n <= kvm_arm_pmu_get_max_counters(kvm))
>> + new_n <= kvm_pmu_hpmn(vcpu))
>> kvm->arch.nr_pmu_counters = new_n;

> This is the legacy UAPI for setting the number of PMU counters by
> writing to PMCR_EL0.N.

> The 'partitioned' implementation should take a dependency on the
> SET_NR_COUNTERS attribute and reject attempts to change the value of
> PMCR_EL0.N. Just like nested.

Good! I hated making writes to PMCR_EL0.N work and only did it because
of selftests assuming it did.

> Thanks,
> Oliver