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@xxxxxxxxxx>
>>> ---
>>> 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.
Thanks
Eric
>
> Thanks,
>
> M.
