linux-kernel - Re: [PATCH v2 4/7] KVM: x86/pmu: Add documentation for fixed ctr on PMU filter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZG+hPaVxYcBq8S5o@google.com>
Date:   Thu, 25 May 2023 10:56:13 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Jinrong Liang <ljr.kernel@...il.com>
Cc:     Like Xu <like.xu.linux@...il.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Jonathan Corbet <corbet@....net>,
        Shuah Khan <shuah@...nel.org>,
        Aaron Lewis <aaronlewis@...gle.com>,
        David Matlack <dmatlack@...gle.com>,
        Vishal Annapurve <vannapurve@...gle.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Bagas Sanjaya <bagasdotme@...il.com>,
        Jinrong Liang <cloudliang@...cent.com>,
        linux-kselftest@...r.kernel.org, linux-doc@...r.kernel.org,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/7] KVM: x86/pmu: Add documentation for fixed ctr on
 PMU filter

On Thu, Apr 20, 2023, Jinrong Liang wrote:
> From: Jinrong Liang <cloudliang@...cent.com>
> 
> From: Jinrong Liang <cloudliang@...cent.com>
> 
> 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@...cent.com>
> Reported-by: kernel test robot <lkp@...el.com>
> Link: https://lore.kernel.org/oe-kbuild-all/202304150850.rx4UDDsB-lkp@intel.com
> Signed-off-by: Jinrong Liang <cloudliang@...cent.com>
> ---

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.
---