Hi Oliver, On Mon, Jan 9, 2023 at 6:01 PM Oliver Upton <oliver.upton@xxxxxxxxx> wrote: > > Hi Reiji, > > On Thu, Dec 29, 2022 at 07:59:21PM -0800, Reiji Watanabe wrote: > > The goal of this series is to allow userspace to limit the number > > of PMU event counters on the vCPU. > > > > The number of PMU event counters is indicated in PMCR_EL0.N. > > For a vCPU with PMUv3 configured, its value will be the same as > > the host value by default. Userspace can set PMCR_EL0.N for the > > vCPU to a lower value than the host value, using KVM_SET_ONE_REG. > > However, it is practically unsupported, as KVM resets PMCR_EL0.N > > to the host value on vCPU reset and some KVM code uses the host > > value to identify (un)implemented event counters on the vCPU. > > > > This series will ensure that the PMCR_EL0.N value is preserved > > on vCPU reset and that KVM doesn't use the host value > > to identify (un)implemented event counters on the vCPU. > > This allows userspace to limit the number of the PMU event > > counters on the vCPU. > > I just wanted to bring up the conversation we had today on the list as > it is a pretty relevant issue. > > KVM currently allows any value to be written to PMCR_EL0.N, meaning that > userspace could advertize more PMCs than are supported by the system. > > IDK if Marc feels otherwise, but it doesn't seem like we should worry > about ABI change here (i.e. userspace can no longer write junk to the > register) as KVM has advertized the correct value to userspace. The only > case that breaks would be a userspace that intentionally sets PMCR_EL0.N > to something larger than the host. As accesses to unadvertized PMC > indices is CONSTRAINED UNPRED behavior, I'm having a hard time coming up > with a use case. Yes, I agree with that. I will be looking at adding the validation of the register field for the v2. Thank you, Reiji
