On Fri, Jun 09, 2023 at 11:15:20PM -0700, Reiji Watanabe wrote: > Disallow userspace from configuring vPMU for guests on systems > where the PMUVer is not uniform across all PEs. > KVM has not been advertising PMUv3 to the guests with vPMU on > such systems anyway, and such systems would be extremely > uncommon and unlikely to even use KVM. Ok... Now your changes are starting to make sense. This patch is rather relevant context for interpreting the other PMU fix [*], so I'd recommend you send this as a combined series going forward. [*] https://lore.kernel.org/kvmarm/20230610194510.4146549-1-reijiw@xxxxxxxxxx/ > diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h > index eef17de966da..af1fe2b53fbb 100644 > --- a/include/kvm/arm_pmu.h > +++ b/include/kvm/arm_pmu.h > @@ -105,6 +105,14 @@ void kvm_vcpu_pmu_restore_host(struct kvm_vcpu *vcpu); > > u8 kvm_arm_pmu_get_pmuver_limit(void); > > +static inline void kvm_arm_set_support_pmu_v3(void) > +{ > + u8 pmuver = kvm_arm_pmu_get_pmuver_limit(); > + > + if (pmu_v3_is_supported(pmuver)) > + static_branch_enable(&kvm_arm_pmu_available); > +} > + > #else > struct kvm_pmu { > }; > @@ -114,6 +122,8 @@ static inline bool kvm_arm_support_pmu_v3(void) > return false; > } > > +static inline void kvm_arm_set_support_pmu_v3(void) {}; > + nit: Give this thing a more generic name (e.g. kvm_pmu_init()) in case we wind up needing more boot-time PMU initialization. -- Thanks, Oliver
