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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Thanks,

        M.
--
Jazz is not dead. It just smells funny...



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux