On Thu, Apr 20, 2023, Jinrong Liang wrote: > From: Jinrong Liang <cloudliang@xxxxxxxxxxx> > > From: Jinrong Liang <cloudliang@xxxxxxxxxxx> > > Update the documentation for the KVM_SET_PMU_EVENT_FILTER ioctl > to include a detailed description of how fixed performance events > are handled in the pmu filter. The action and fixed_counter_bitmap > members of the pmu filter to determine whether fixed performance > events can be programmed by the guest. This information is helpful > for correctly configuring the fixed_counter_bitmap and action fields > to filter fixed performance events. > > Suggested-by: Like Xu <likexu@xxxxxxxxxxx> > Reported-by: kernel test robot <lkp@xxxxxxxxx> > Link: https://lore.kernel.org/oe-kbuild-all/202304150850.rx4UDDsB-lkp@xxxxxxxxx > Signed-off-by: Jinrong Liang <cloudliang@xxxxxxxxxxx> > --- Please post this separately from the selftests changes. > 1 file changed, 21 insertions(+) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index a69e91088d76..b5836767e0e7 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -5122,6 +5122,27 @@ Valid values for 'action':: > #define KVM_PMU_EVENT_ALLOW 0 > #define KVM_PMU_EVENT_DENY 1 > > +Via this API, KVM userspace can also control the behavior of the VM's fixed > +counters (if any) by configuring the "action" and "fixed_counter_bitmap" fields. > + > +Specifically, KVM follows the following pseudo-code when determining whether to > +allow the guest FixCtr[i] to count its pre-defined fixed event:: > + > + FixCtr[i]_is_allowed = (action == ALLOW) && (bitmap & BIT(i)) || > + (action == DENY) && !(bitmap & BIT(i)); > + FixCtr[i]_is_denied = !FixCtr[i]_is_allowed; > + > +Note once this API interface is called, the default zero value of the field No, there is no "default" value. Userspace provides the exact value. The KVM *selftest* clears fixed_counter_bitmap in all cases, but there is no default anywhere. > +"fixed_counter_bitmap" will implicitly affect all fixed counters, even if it's There is no implicit behavior, userspace very explicitly provides fixed_counter_bitmap. > +expected to be used only to control the events on generic counters. I would rather phrase this as: --- KVM always consumes fixed_counter_bitmap, it's userspace's responsibility to ensure fixed_counter_bitmap is set correctly, e.g. if userspace wants to define a filter that only affects general purpose counters. --- > +In addition, pre-defined performance events on the fixed counters already have > +event_select and unit_mask values defined, which means userspace can also > +control fixed counters by configuring "action"+ "events" fields. > > +When there is a contradiction between these two polices, the fixed performance > +counter will only follow the rule of the pseudo-code above. This is unnecessary vague. I think what you're saying is, with a slight reword of the first paragraph too: --- Note, the "events" field also applies to fixed counters' hardcoded event_select and unit_mask values. "fixed_counter_bitmap" has higher priority than "events" if there is a contradiction between the two. ---
