On Wed, Sep 09, 2020 at 10:43:41AM +0200, Alexander Graf wrote: > Hey Drew! > > On 09.09.20 08:25, Andrew Jones wrote: > > > > On Tue, Sep 08, 2020 at 10:57:30PM +0200, Alexander Graf wrote: > > > We currently pass through the number of PMU counters that we have available > > > in hardware to guests. So if my host supports 10 concurrently active PMU > > > counters, my guest will be able to spawn 10 counters as well. > > > > > > This is undesireable if we also want to use the PMU on the host for > > > monitoring. In that case, we want to split the PMU between guest and > > > host. > > > > > > To help that case, let's add a PMU attr that allows us to limit the number > > > of PMU counters that we expose. With this patch in place, user space can > > > keep some counters free for host use. > > > > Hi Alex, > > > > Is there any reason to use the device API instead of just giving the user > > control over the necessary PMCR_EL0 bits through set/get-one-reg? > > I mostly used the attr interface because I was in that particular mental > mode after looking at the filtering bits :). > > Today, the PMCR_EL0 register gets reset implicitly on every vcpu reset call. > How would we persist the counter field across resets? Would we in the first > place? > > I'm slightly hazy how the ONE_REG API would look like here. Do you have > recommendations? > Using the set/get_user hooks of the sysreg table we can accept a user input PMCR_EL0. We would only accept one that matches what the hardware and KVM supports though (EINVAL otherwise). We'll need to modify reset to use the value selected by the user too, which we can store in 'val' of the sysreg table. Since userspace will likely get before set in order to know what's valid, we'll need to provide the current reset state on get until it has been set. I'm not sure how to track whether it has been set or not. Maybe new state is needed or an initial val=0 or val=~0 may work. Thanks, drew
