| Message ID | 20200309124837.19908-3-maz@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: arm64: Filtering PMU events | expand |
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? > + ======= ====================================================== > + > +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? 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? > + > +Restrictions: Event 0 (SW_INCR) is never filtered, as it doesn't count a > +hardware event. Filtering event 0x1E (CHAIN) has no effect either, as it > +isn't strictly speaking an event. Filtering the cycle counter is possible > +using event 0x11 (CPU_CYCLES). Thanks Eric > + > > 2. GROUP: KVM_ARM_VCPU_TIMER_CTRL > ================================= >
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. Thanks, M.
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. Thanks Eric > > Thanks, > > M.
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.
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 + ======= ====================================================== + +Request the installation of a PMU event filter describe as follows: + +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. + +Restrictions: Event 0 (SW_INCR) is never filtered, as it doesn't count a +hardware event. Filtering event 0x1E (CHAIN) has no effect either, as it +isn't strictly speaking an event. Filtering the cycle counter is possible +using event 0x11 (CPU_CYCLES). + 2. GROUP: KVM_ARM_VCPU_TIMER_CTRL =================================
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(+)