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