Re: [PATCH v2 2/2] KVM: arm64: Document PMU filtering API

[Marc Zyngier <maz@kernel.org>]

On 2020-03-10 17:30, Auger Eric wrote:
> Hi Marc,
> 
> On 3/10/20 12:54 PM, Marc Zyngier wrote:
>> On 2020-03-09 18:17, Auger Eric wrote:
>>> Hi Marc,
>>> 
>>> On 3/9/20 1:48 PM, Marc Zyngier wrote:
>>>> Add a small blurb describing how the event filtering API gets used.
>>>> 
>>>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>>>> ---
>>>>  Documentation/virt/kvm/devices/vcpu.rst | 40 
>>>> +++++++++++++++++++++++++
>>>>  1 file changed, 40 insertions(+)
>>>> 
>>>> diff --git a/Documentation/virt/kvm/devices/vcpu.rst
>>>> b/Documentation/virt/kvm/devices/vcpu.rst
>>>> index 9963e680770a..7262c0469856 100644
>>>> --- a/Documentation/virt/kvm/devices/vcpu.rst
>>>> +++ b/Documentation/virt/kvm/devices/vcpu.rst
>>>> @@ -55,6 +55,46 @@ Request the initialization of the PMUv3.  If 
>>>> using
>>>> the PMUv3 with an in-kernel
>>>>  virtual GIC implementation, this must be done after initializing 
>>>> the
>>>> in-kernel
>>>>  irqchip.
>>>> 
>>>> +1.3 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_FILTER
>>>> +---------------------------------------
>>>> +
>>>> +:Parameters: in kvm_device_attr.addr the address for a PMU event
>>>> filter is a
>>>> +             pointer to a struct kvm_pmu_event_filter
>>>> +
>>>> +:Returns:
>>>> +
>>>> +     =======  
>>>> ======================================================
>>>> +     -ENODEV: PMUv3 not supported or GIC not initialized
>>>> +     -ENXIO:  PMUv3 not properly configured or in-kernel irqchip 
>>>> not
>>>> +           configured as required prior to calling this attribute
>>>> +     -EBUSY:  PMUv3 already initialized
>>> maybe document -EINVAL?
>> 
>> Yup, definitely.
>> 
>>>> +     =======  
>>>> ======================================================
>>>> +
>>>> +Request the installation of a PMU event filter describe as follows:
>>> s/describe/described
>>>> +
>>>> +struct kvm_pmu_event_filter {
>>>> +    __u16    base_event;
>>>> +    __u16    nevents;
>>>> +
>>>> +#define KVM_PMU_EVENT_ALLOW    0
>>>> +#define KVM_PMU_EVENT_DENY    1
>>>> +
>>>> +    __u8    action;
>>>> +    __u8    pad[3];
>>>> +};
>>>> +
>>>> +A filter range is defined as the range [@base_event, @base_event +
>>>> @nevents[,
>>>> +together with an @action (KVM_PMU_EVENT_ALLOW or
>>>> KVM_PMU_EVENT_DENY). The
>>>> +first registered range defines the global policy (global ALLOW if
>>>> the first
>>>> +@action is DENY, global DENY if the first @action is ALLOW).
>>>> Multiple ranges
>>>> +can be programmed, and must fit within the 16bit space defined by
>>>> the ARMv8.1
>>>> +PMU architecture.
>>> what about before 8.1 where the range was 10 bits? Should it be 
>>> tested
>>> in the code?
>> 
>> It's a good point. We could test that upon installing the filter and 
>> limit
>> the bitmap allocation to the minimum.
>> 
>>> nitpicking: It is not totally obvious what does happen if the user 
>>> space
>>> sets a deny filter on a range and then an allow filter on the same
>>> range. it is supported but may be worth telling so? Also explain the 
>>> the
>>> default filtering remains "allow" by default?
>> 
>> Overlapping filters are easy: the last one wins. And yes, no filter 
>> means
>> just that: no filter.
> Actually the point I wanted to put forward is
> 1) set allow filter on range [0-a] -> default setting is deny and allow
> [0-a] only
> 2) deny deny filter on rang [0-a] -> there is no "real" active 
> filtering
> anymore but default behavior still is deny. ie. you do not destroy the
> bitmap on the last filter removal but on the VM removal.

Ah, gotcha. Yes, this is odd. The solution to this is to re-apply a 
default
behaviour. But this needs documenting...

Thanks,

        M.
-- 
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm