Re: [PATCH V2 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support
On Mon, 2017-11-20 at 15:10 +0100, Jiri Olsa wrote: > On Fri, Nov 17, 2017 at 05:54:05PM -0800, Megha Dey wrote: > > SNIP > > > +/* Branch Monitoring default and mask values */ > > +#define BM_MAX_WINDOW_SIZE 0x3ff > > +#define BM_MAX_THRESHOLD 0x7f > > +#define BM_MAX_EVENTS 6 > > +#define BM_WINDOW_SIZE_SHIFT 8 > > +#define BM_THRESHOLD_SHIFT 8 > > +#define BM_EVENT_TYPE_SHIFT1 > > +#define BM_GUEST_DISABLE_SHIFT 3 > > +#define BM_LBR_FREEZE_SHIFT2 > > +#define BM_WINDOW_CNT_SEL_SHIFT24 > > +#define BM_CNT_AND_MODE_SHIFT 26 > > +#define BM_MISPRED_EVT_CNT_SHIFT 15 > > +#define BM_ENABLE 0x3 > > +#define BM_CNTR_ENABLE 1 > > + > > +static unsigned int bm_window_size = BM_MAX_WINDOW_SIZE; > > +static unsigned int bm_guest_disable; > > +static unsigned int bm_lbr_freeze; > > +static unsigned int bm_window_cnt_sel; > > +static unsigned int bm_cnt_and_mode; > > + > > +static unsigned int bm_threshold = BM_MAX_THRESHOLD; > > +static unsigned int bm_mispred_evt_cnt; > > + > > +/* Branch monitoring counter owners */ > > +static struct perf_event **bm_counter_owner; > > that's still global.. 2 counters per system Yes, you are right . I will amend this in the next patch set. > > jirka -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 3/3] x86, bm: Add documentation on Intel Branch Monitoring
On Mon, 2017-11-20 at 15:07 +0100, Jiri Olsa wrote: > On Fri, Nov 17, 2017 at 05:54:06PM -0800, Megha Dey wrote: > > SNIP > > > +IV. User-configurable inputs > > + > > + > > +Several sysfs entries are provided in /sys/devices/intel_bm/ to configure > > +controls for the supported hardware heuristics. > > + > > +1. LBR freeze: /sys/devices/intel-bm/lbr_freeze > > + possible values are 0 or 1. By default this is disabled(0). When > > enabled, > > + an LBR freeze is observed on threshold trip > > + > > +2. Guest Disable: /sys/devices/intel-bm/guest_disable > > + Possible values are 0 or 1. By default it is 0. When set to ‘1’, branch > > + monitoring feature is disabled when operating at VMX non-root operation. > > + > > +3. Window size: /sys/devices/intel-bm/window_size > > + By default, window size is 1023. It can take values from 0 to 1023. This > > + represents the number of instructions to be executed before the event > > + counters are reset. > > + > > +4. Window count select: /sys/devices/intel-bm/window_cnt_sel > > + Possible values are: > > + ‘00 = instructions retired > > + ‘01 = branches retired > > + ‘10 = returned instructions retired > > + ‘11 = indirect branch instructions retired > > + By default, it has a value of 0. > > + > > +5. Count and mode: /sys/devices/intel-bm/cnt_and_mode > > + Possible values are 0 or 1. By default it is 0. When set to ‘1’, the > > + overall event triggering condition is true only if both enabled > > + counter’s threshold conditions are true. When ‘0’, the threshold > > + tripping condition is true if either enabled counter’s threshold is > > + true. If a counter is not enabled, then it does not factor into the > > + AND’ing logic > > + > > +6. Threshold: /sys/devices/intel-bm/threshold > > + An unsigned value of 0 to 127 is supported. The value 0 of counter > > + threshold will result in branch monitoring event signaled after every > > + instruction. By default, it has a value of 127. > > + > > +7. Mispredict counting behaviour: /sys/devices/intel-bm/mispred_evt_cnt > > + Possible values are: > > + 0 = mispredict events are counted in a window > > + 1 = mispredict events are counted based on a consecutive occurrence. > > + By default, it has a value of 0. > > you use all those value to configure the event: > > event->hw.bm_ctrl = (bm_window_size << BM_WINDOW_SIZE_SHIFT) | > (bm_guest_disable << BM_GUEST_DISABLE_SHIFT) | > (bm_lbr_freeze << BM_LBR_FREEZE_SHIFT) | > (bm_window_cnt_sel << BM_WINDOW_CNT_SEL_SHIFT) | > (bm_cnt_and_mode << BM_CNT_AND_MODE_SHIFT) | > BM_ENABLE; > event->hw.bm_counter_conf = (bm_threshold << BM_THRESHOLD_SHIFT) | > (bm_mispred_evt_cnt << BM_MISPRED_EVT_CNT_SHIFT) | > (cfg << BM_EVENT_TYPE_SHIFT) | BM_CNTR_ENABLE; > > I wonder you should place this under perf_event_attr::config/config1 > and define them in /sys/devices/intel_bm/format/... like we do for > cpu pmu > > then you could use perf stat -e like: '-e > intel_bm/call-ret,threshold=...,lbr_freeze/' Thanks for the suggestion! I will implement this in the next patch set. > > jirka -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support
On Mon, 2017-11-20 at 12:57 +0100, Peter Zijlstra wrote:
> On Fri, Nov 17, 2017 at 05:54:05PM -0800, Megha Dey wrote:
> > + mutex_lock(_counter_mutex);
> > + for (i = 0; i < BM_MAX_COUNTERS; i++) {
> > + if (bm_counter_owner[i] == NULL) {
> > + counter_to_use = i;
> > + bm_counter_owner[i] = event;
> > + break;
> > + }
> > + }
> > + mutex_unlock(_counter_mutex);
> > +
> > + if (counter_to_use == -1)
> > + return -EBUSY;
>
> > +static struct pmu intel_bm_pmu = {
> > + .task_ctx_nr = perf_sw_context,
> > + .attr_groups = intel_bm_attr_groups,
> > + .event_init = intel_bm_event_init,
> > + .add = intel_bm_event_add,
> > + .del = intel_bm_event_del,
> > +};
>
> Still horrid.. still no.
It seems like perf_invalid_context does not support per task monitoring:
find_get_context():
ctxn = pmu->task_ctx_nr;
if (ctxn < 0)
goto errout;
Also, perf_hw_context is to be used only for core PMU, correct?
That leaves us with only perf_sw_context to be used. Not sure if a new
context needs to be implemented.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support
On Tue, 2017-12-12 at 23:32 +0100, Peter Zijlstra wrote:
> On Tue, Dec 12, 2017 at 01:10:57PM -0800, Megha Dey wrote:
> > On Mon, 2017-11-20 at 12:57 +0100, Peter Zijlstra wrote:
> > > On Fri, Nov 17, 2017 at 05:54:05PM -0800, Megha Dey wrote:
> > > > + mutex_lock(_counter_mutex);
> > > > + for (i = 0; i < BM_MAX_COUNTERS; i++) {
> > > > + if (bm_counter_owner[i] == NULL) {
> > > > + counter_to_use = i;
> > > > + bm_counter_owner[i] = event;
> > > > + break;
> > > > + }
> > > > + }
> > > > + mutex_unlock(_counter_mutex);
> > > > +
> > > > + if (counter_to_use == -1)
> > > > + return -EBUSY;
> > >
> > > > +static struct pmu intel_bm_pmu = {
> > > > + .task_ctx_nr = perf_sw_context,
> > > > + .attr_groups = intel_bm_attr_groups,
> > > > + .event_init = intel_bm_event_init,
> > > > + .add = intel_bm_event_add,
> > > > + .del = intel_bm_event_del,
> > > > +};
> > >
> > > Still horrid.. still no.
> >
> > It seems like perf_invalid_context does not support per task monitoring:
> > find_get_context():
> > ctxn = pmu->task_ctx_nr;
> > if (ctxn < 0)
> > goto errout;
> >
> > Also, perf_hw_context is to be used only for core PMU, correct?
> >
> > That leaves us with only perf_sw_context to be used. Not sure if a new
> > context needs to be implemented.
>
> There's work on the way to allow multiple HW PMUs. You'll either have to
> wait for that or help in making that happen. What you do not do is
> silently hack around it.
Could I get a pointer to the code implementing this?
I assume that this patch cannot be accepted until there is a way to
allow multiple HW PMUs even if appropriate comments are added?
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 0/3] perf/x86/intel: Add Branch Monitoring support
This patchset adds support for Intel's branch monitoring feature. This feature uses heuristics to detect the occurrence of an ROP(Return Oriented Programming) or ROP like(JOP: Jump oriented programming) attack. These heuristics are based off certain performance monitoring statistics, measured dynamically over a short configurable window period. ROP is a malware trend in which the attacker can compromise a return pointer held on the stack to redirect execution to a different desired instruction. Currently, only the Cannonlake family of Intel processors support this feature. This feature is enabled by CONFIG_PERF_EVENTS_INTEL_BM. Once the kernel is compiled with CONFIG_PERF_EVENTS_INTEL_BM=y on a Cannonlake system, the following perf events are added which can be viewed with perf list: intel_bm/branch-misp/ [Kernel PMU event] intel_bm/call-ret/ [Kernel PMU event] intel_bm/far-branch/ [Kernel PMU event] intel_bm/indirect-branch-misp/ [Kernel PMU event] intel_bm/ret-misp/ [Kernel PMU event] intel_bm/rets/ [Kernel PMU event] A perf-based kernel driver has been used to monitor the occurrence of one of the 6 branch monitoring events. There are 2 counters that each can select between one of these events for evaluation over a specified instruction window size (0 to 1023). For each counter, a threshold value (0 to 127) can be configured to set a point at which an interrupt is generated. Each task can monitor a maximum of 2 events at any given time. Apart from the kernel driver, this patchset adds CPUID of Cannonlake processors to Intel family list and the Documentation/x86/intel_bm.txt file with some information about Intel Branch monitoring. Changes V0->V1: 1. Used the 'is_sampling_event' function 2. Added support to monitor 2 events for every task 3. Corrected typos 4. Added a lock to prevent race condition in concurrent perf_event_open()s 5. Got rid of start()/stop() and added its functionality in add()/del() 6. Removed read() callback as it was not doing anything. 6. Removed code for sampling events as we do not support sampling. 7. Added 'id' member to hw_perf_event::intel_bm to track which counter the event is using. 8. Moved MSR accesses to the add()/del() callbacks Changes V1->V2: 1. Edited commit message to make things less ambiguous 2. Corrected the Signed-off-by chain 3. Used a named construct for the counter enable bit 4. Added the corrected logic to unmask NMI bit of local APIC only for the first time a task is scheduled on a CPU. Removed the separate function 5. Restructured code in the NMI handler to save convoluted indentation 6. Removed the redundant read of the status register in add() 7. Removed the update function as it did not do what it is supposed to do Added this code to del() instead 8. Corrected the polarity of 'is_sampling_event' function when used 9. Removed the setting of event->count to 0 in event_init. This is redundant as this is its default value 10. Do not allow threshold to be set as 0 Megha Dey (3): x86/cpu/intel: Add Cannonlake to Intel family perf/x86/intel/bm.c: Add Intel Branch Monitoring support x86, bm: Add documentation on Intel Branch Monitoring Documentation/x86/intel_bm.txt | 216 + arch/x86/events/Kconfig | 10 + arch/x86/events/intel/Makefile | 2 + arch/x86/events/intel/bm.c | 605 arch/x86/include/asm/intel-family.h | 2 + arch/x86/include/asm/msr-index.h| 5 + arch/x86/include/asm/processor.h| 4 + include/linux/perf_event.h | 9 +- kernel/events/core.c| 16 + 9 files changed, 868 insertions(+), 1 deletion(-) create mode 100644 Documentation/x86/intel_bm.txt create mode 100644 arch/x86/events/intel/bm.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/3] x86/cpu/intel: Add Cannonlake to Intel family
Add CPUID of Cannonlake (CNL) processors to Intel family list. Signed-off-by: Megha Dey <megha@linux.intel.com> --- arch/x86/include/asm/intel-family.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h index 35a6bc4..056bd41 100644 --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -65,6 +65,8 @@ #define INTEL_FAM6_ATOM_DENVERTON 0x5F /* Goldmont Microserver */ #define INTEL_FAM6_ATOM_GEMINI_LAKE0x7A +#define INTEL_FAM6_CANNONLAKE_MOBILE 0x66 + /* Xeon Phi */ #define INTEL_FAM6_XEON_PHI_KNL0x57 /* Knights Landing */ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 3/3] x86, bm: Add documentation on Intel Branch Monitoring
This patch adds the Documentation/x86/intel_bm.txt file with some information about Intel Branch monitoring. Signed-off-by: Megha Dey <megha@linux.intel.com> --- Documentation/x86/intel_bm.txt | 216 + 1 file changed, 216 insertions(+) create mode 100644 Documentation/x86/intel_bm.txt diff --git a/Documentation/x86/intel_bm.txt b/Documentation/x86/intel_bm.txt new file mode 100644 index 000..25b7177 --- /dev/null +++ b/Documentation/x86/intel_bm.txt @@ -0,0 +1,216 @@ +Intel(R) Branch Monitoring + +Copyright (C) 2017 Intel Corporation + +Megha Dey <megha@intel.com> +Yu-Cheng Yu <yu-cheng...@intel.com> + +I. Overview +=== + +The Cannonlake family of Intel processors support the branch monitoring +feature. This feature uses heuristics to detect the occurrence of an ROP +(Return Oriented Programming) or ROP like(JOP:Jump oriented programming) +attack. These heuristics are based off certain performance monitoring +statistics, measured dynamically over a short configurable window period. +ROP is a malware trend in which the attacker can compromise a return +pointer held on the stack to redirect execution to a different desired +instruction. + +Support for branch monitoring has been added via Linux kernel perf event +infrastructure. This feature is enabled by CONFIG_PERF_EVENTS_INTEL_BM. + +Once the kernel is compiled with CONFIG_PERF_EVENTS_INTEL_BM=y on a +Cannonlake system, the following perf events are added which can be viewed +with perf list: + intel_bm/branch-misp/ [Kernel PMU event] + intel_bm/call-ret/ [Kernel PMU event] + intel_bm/far-branch/ [Kernel PMU event] + intel_bm/indirect-branch-misp/ [Kernel PMU event] + intel_bm/ret-misp/ [Kernel PMU event] + intel_bm/rets/ [Kernel PMU event] + +II. Hardware details + + +The MSRs associated with branch monitoring are as follows: + +1. BR_DETECT_CTRL : Branch Monitoring Global control + Used for enabling and configuring global capability + +2. BR_DETECT_STATUS : Branch Monitoring Global Status + Used by SW handler for determining detect status + +3. BR_DETECT_COUNTER_CONFIG_i : Branch Monitoring Counter Configuration + Per-cpu branch monitoring counter Configuration + +There are 2 8-bit counters that each can select between one of the +following 6 events: + +1. RET instructions: Counts the number of near return instructions retired + +2. CALL-RET instructions: Counts the difference between the number of near + return and call instructions retired + +3. RET mispredicts: Mispredicted return instructions retired + +4. Branch (all) mispredicts: Counts the number of mispredicted branches + +5. Indirect branch mispredicts: Counts the number of mispredicted indirect + near branch instructions. Includes indirect near jump/call instructions + +6. Far branch instructions: Counts the number of far branches retired + +Branch Monitoring hardware utilizes various existing performance related +counter events. Of the 6 events above, only call-ret is newly implemented. + +The events are evaluated over a specified 10-bit instruction window size +(0 to 1023). For each counter, a threshold value (0 to 127) can be +configured to set a point at which an interrupt is generated and a +detection event action is taken (determined by user-space). This can take +the form of signaling an interrupt and/or freezing the state of the last +branch record information. + +The event counters are reset after every 'window size' instructions by the +hardware. + +The feature is for user mode (privilege level > 0) operation only, which is +the known malware security threat target environment. While in supervisor +mode, this heuristic detection counter activity is suspended. This behavior +(user mode) is independent of root vs. non-root with respect to +virtualization technology execution. + +III. Software Implementation + + +A perf-based kernel driver has been used to monitor the occurrence of +one of the 6 branch monitoring events. + +If an branch monitoring interrupt is generated, the interrupt bit is set +which is cleared by interrupt handler and the event counters are reset. + +The entire system can monitor a maximum of 2 events at any given time. +These events can belong to the same or different tasks. + +Everytime a task is scheduled out, we save current window and count +associated with the event being monitored. When the task is scheduled next, +we start counting from previous count associated with this event. Thus, a +full context switch in this case is not necessary. + +The Branch Monitoring exception can be configured as a regular interrupt or +an NMI. We chain an NMI handler after PMU, because +1. It will not interfere with PMU events +2. We only monitor
[PATCH V1 0/3] perf/x86/intel: Add Branch Monitoring support
This patchset adds support for Intel's branch monitoring feature. This feature uses heuristics to detect the occurrence of an ROP(Return Oriented Programming) or ROP like(JOP: Jump oriented programming) attack. These heuristics are based off certain performance monitoring statistics, measured dynamically over a short configurable window period. ROP is a malware trend in which the attacker can compromise a return pointer held on the stack to redirect execution to a different desired instruction. Currently, only the Cannonlake family of Intel processors support this feature. This feature is enabled by CONFIG_PERF_EVENTS_INTEL_BM. Once the kernel is compiled with CONFIG_PERF_EVENTS_INTEL_BM=y on a Cannonlake system, the following perf events are added which can be viewed with perf list: intel_bm/branch-misp/ [Kernel PMU event] intel_bm/call-ret/ [Kernel PMU event] intel_bm/far-branch/ [Kernel PMU event] intel_bm/indirect-branch-misp/ [Kernel PMU event] intel_bm/ret-misp/ [Kernel PMU event] intel_bm/rets/ [Kernel PMU event] A perf-based kernel driver has been used to monitor the occurrence of one of the 6 branch monitoring events. There are 2 counters that each can select between one of these events for evaluation over a specified instruction window size (0 to 1023). For each counter, a threshold value (0 to 127) can be configured to set a point at which an interrupt is generated. Each task can monitor a maximum of 2 events at any given time. Apart from the kernel driver, this patchset adds CPUID of Cannonlake processors to Intel family list and the Documentation/x86/intel_bm.txt file with some information about Intel Branch monitoring. Changes V0->V1: 1. Used the 'is_sampling_event' function 2. Added support to monitor 2 events for every task 3. Corrected typos 4. Added a lock to prevent race condition in concurrent perf_event_open()s 5. Got rid of start()/stop() and added its functionality in add()/del() 6. Removed read() callback as it was not doing anything. 6. Removed code for sampling events as we do not support sampling. 7. Added 'id' member to hw_perf_event::intel_bm to track which counter the event is using. 8. Moved MSR accesses to the add()/del() callbacks Megha Dey (3): x86/cpu/intel: Add Cannonlake to Intel family perf/x86/intel/bm.c: Add Intel Branch Monitoring support x86, bm: Add documentation on Intel Branch Monitoring Documentation/x86/intel_bm.txt | 216 + arch/x86/events/Kconfig | 10 + arch/x86/events/intel/Makefile | 2 + arch/x86/events/intel/bm.c | 618 arch/x86/include/asm/intel-family.h | 2 + arch/x86/include/asm/msr-index.h| 5 + arch/x86/include/asm/processor.h| 4 + include/linux/perf_event.h | 9 +- kernel/events/core.c| 16 + 9 files changed, 881 insertions(+), 1 deletion(-) create mode 100644 Documentation/x86/intel_bm.txt create mode 100644 arch/x86/events/intel/bm.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V1 1/3] x86/cpu/intel: Add Cannonlake to Intel family
Add CPUID of Cannonlake (CNL) processors to Intel family list. Signed-off-by: Megha Dey <megha@linux.intel.com> --- arch/x86/include/asm/intel-family.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h index 35a6bc4..056bd41 100644 --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -65,6 +65,8 @@ #define INTEL_FAM6_ATOM_DENVERTON 0x5F /* Goldmont Microserver */ #define INTEL_FAM6_ATOM_GEMINI_LAKE0x7A +#define INTEL_FAM6_CANNONLAKE_MOBILE 0x66 + /* Xeon Phi */ #define INTEL_FAM6_XEON_PHI_KNL0x57 /* Knights Landing */ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V1 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support
Currently, the cannonlake family of Intel processors support the
branch monitoring feature. Intel's Branch monitoring feature is trying
to utilize heuristics to detect the occurrence of an ROP (Return
Oriented Programming) attack.
A perf-based kernel driver has been used to monitor the occurrence of
one of the 6 branch monitoring events. There are 2 counters that each
can select between one of these events for evaluation over a specified
instruction window size (0 to 1023). For each counter, a threshold value
(0 to 127) can be configured to set a point at which ROP detection event
action is taken (determined by user-space). Each task can monitor
a maximum of 2 events at any given time.
Apart from window_size(global) and threshold(per-counter), various sysfs
entries are provided for the user to configure: guest_disable, lbr_freeze,
window_cnt_sel, cnt_and_mode (all global) and mispred_evt_cnt(per-counter).
For all events belonging to the same task, the global parameters are
shared.
Everytime a task is scheduled out, we save current window and count
associated with the event being monitored. When the task is scheduled
next, we start counting from previous count associated with this event.
Thus, a full context switch in this case is not necessary.
To monitor a user space application for ROP related events, perf command
line can be used as follows:
perf stat -e
eg. For the following test program (test.c) and threshold = 100
(echo 100 > /sys/devices/intel_bm/threshold)
void func(void)
{
return;
}
void main(void)
{
int i;
for (i = 0; i < 128; i++) {
func();
}
return;
}
perf stat -e intel_bm/rets/ ./test
Performance counter stats for './test':
1 intel_bm/rets/
0.104705937 seconds time elapsed
perf returns the number of branch monitoring interrupts occurred during
the execution of the user-space application.
Signed-off-by: Megha Dey <megha@linux.intel.com>
Signed-off-by: Yu-Cheng Yu <yu-cheng...@intel.com>
---
arch/x86/events/Kconfig | 10 +
arch/x86/events/intel/Makefile | 2 +
arch/x86/events/intel/bm.c | 618 +++
arch/x86/include/asm/msr-index.h | 5 +
arch/x86/include/asm/processor.h | 4 +
include/linux/perf_event.h | 9 +-
kernel/events/core.c | 16 +
7 files changed, 663 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/events/intel/bm.c
diff --git a/arch/x86/events/Kconfig b/arch/x86/events/Kconfig
index 9a7a144..40903ca 100644
--- a/arch/x86/events/Kconfig
+++ b/arch/x86/events/Kconfig
@@ -9,6 +9,16 @@ config PERF_EVENTS_INTEL_UNCORE
Include support for Intel uncore performance events. These are
available on NehalemEX and more modern processors.
+config PERF_EVENTS_INTEL_BM
+ bool "Intel Branch Monitoring support"
+ depends on PERF_EVENTS && CPU_SUP_INTEL && PCI
+ ---help---
+ Include support for Intel Branch monitoring. This feature utilizes
+ heuristics for detecting ROP(Return oriented programming) like
+ attacks. These heuristics are based off certain performance
+ monitoring statistics, measured dynamically over a short
+ configurable window period.
+
config PERF_EVENTS_INTEL_RAPL
tristate "Intel rapl performance events"
depends on PERF_EVENTS && CPU_SUP_INTEL && PCI
diff --git a/arch/x86/events/intel/Makefile b/arch/x86/events/intel/Makefile
index 3468b0c..14235ec 100644
--- a/arch/x86/events/intel/Makefile
+++ b/arch/x86/events/intel/Makefile
@@ -2,6 +2,8 @@
obj-$(CONFIG_CPU_SUP_INTEL)+= core.o bts.o
obj-$(CONFIG_CPU_SUP_INTEL)+= ds.o knc.o
obj-$(CONFIG_CPU_SUP_INTEL)+= lbr.o p4.o p6.o pt.o
+obj-$(CONFIG_PERF_EVENTS_INTEL_BM) += intel-bm-perf.o
+intel-bm-perf-objs := bm.o
obj-$(CONFIG_PERF_EVENTS_INTEL_RAPL) += intel-rapl-perf.o
intel-rapl-perf-objs := rapl.o
obj-$(CONFIG_PERF_EVENTS_INTEL_UNCORE) += intel-uncore.o
diff --git a/arch/x86/events/intel/bm.c b/arch/x86/events/intel/bm.c
new file mode 100644
index 000..923c6e9
--- /dev/null
+++ b/arch/x86/events/intel/bm.c
@@ -0,0 +1,618 @@
+/*
+ * Support for Intel branch monitoring counters
+ *
+ * Intel branch monitoring MSRs are specified in the Intel® 64 and IA-32
+ * Software Developer’s Manual Volume 4 section 2.16.2 (October 2017)
+ *
+ * Copyright (c) 2017, Intel Corporation.
+ *
+ * Contact Information:
+ * Megha Dey <megha@linux.intel.com>
+ * Yu-Cheng Yu <yu-cheng...@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ *
[PATCH V1 3/3] x86, bm: Add documentation on Intel Branch Monitoring
This patch adds the Documentation/x86/intel_bm.txt file with some information about Intel Branch monitoring. Signed-off-by: Megha Dey <megha@linux.intel.com> --- Documentation/x86/intel_bm.txt | 216 + 1 file changed, 216 insertions(+) create mode 100644 Documentation/x86/intel_bm.txt diff --git a/Documentation/x86/intel_bm.txt b/Documentation/x86/intel_bm.txt new file mode 100644 index 000..25b7177 --- /dev/null +++ b/Documentation/x86/intel_bm.txt @@ -0,0 +1,216 @@ +Intel(R) Branch Monitoring + +Copyright (C) 2017 Intel Corporation + +Megha Dey <megha@intel.com> +Yu-Cheng Yu <yu-cheng...@intel.com> + +I. Overview +=== + +The Cannonlake family of Intel processors support the branch monitoring +feature. This feature uses heuristics to detect the occurrence of an ROP +(Return Oriented Programming) or ROP like(JOP:Jump oriented programming) +attack. These heuristics are based off certain performance monitoring +statistics, measured dynamically over a short configurable window period. +ROP is a malware trend in which the attacker can compromise a return +pointer held on the stack to redirect execution to a different desired +instruction. + +Support for branch monitoring has been added via Linux kernel perf event +infrastructure. This feature is enabled by CONFIG_PERF_EVENTS_INTEL_BM. + +Once the kernel is compiled with CONFIG_PERF_EVENTS_INTEL_BM=y on a +Cannonlake system, the following perf events are added which can be viewed +with perf list: + intel_bm/branch-misp/ [Kernel PMU event] + intel_bm/call-ret/ [Kernel PMU event] + intel_bm/far-branch/ [Kernel PMU event] + intel_bm/indirect-branch-misp/ [Kernel PMU event] + intel_bm/ret-misp/ [Kernel PMU event] + intel_bm/rets/ [Kernel PMU event] + +II. Hardware details + + +The MSRs associated with branch monitoring are as follows: + +1. BR_DETECT_CTRL : Branch Monitoring Global control + Used for enabling and configuring global capability + +2. BR_DETECT_STATUS : Branch Monitoring Global Status + Used by SW handler for determining detect status + +3. BR_DETECT_COUNTER_CONFIG_i : Branch Monitoring Counter Configuration + Per-cpu branch monitoring counter Configuration + +There are 2 8-bit counters that each can select between one of the +following 6 events: + +1. RET instructions: Counts the number of near return instructions retired + +2. CALL-RET instructions: Counts the difference between the number of near + return and call instructions retired + +3. RET mispredicts: Mispredicted return instructions retired + +4. Branch (all) mispredicts: Counts the number of mispredicted branches + +5. Indirect branch mispredicts: Counts the number of mispredicted indirect + near branch instructions. Includes indirect near jump/call instructions + +6. Far branch instructions: Counts the number of far branches retired + +Branch Monitoring hardware utilizes various existing performance related +counter events. Of the 6 events above, only call-ret is newly implemented. + +The events are evaluated over a specified 10-bit instruction window size +(0 to 1023). For each counter, a threshold value (0 to 127) can be +configured to set a point at which an interrupt is generated and a +detection event action is taken (determined by user-space). This can take +the form of signaling an interrupt and/or freezing the state of the last +branch record information. + +The event counters are reset after every 'window size' instructions by the +hardware. + +The feature is for user mode (privilege level > 0) operation only, which is +the known malware security threat target environment. While in supervisor +mode, this heuristic detection counter activity is suspended. This behavior +(user mode) is independent of root vs. non-root with respect to +virtualization technology execution. + +III. Software Implementation + + +A perf-based kernel driver has been used to monitor the occurrence of +one of the 6 branch monitoring events. + +If an branch monitoring interrupt is generated, the interrupt bit is set +which is cleared by interrupt handler and the event counters are reset. + +The entire system can monitor a maximum of 2 events at any given time. +These events can belong to the same or different tasks. + +Everytime a task is scheduled out, we save current window and count +associated with the event being monitored. When the task is scheduled next, +we start counting from previous count associated with this event. Thus, a +full context switch in this case is not necessary. + +The Branch Monitoring exception can be configured as a regular interrupt or +an NMI. We chain an NMI handler after PMU, because +1. It will not interfere with PMU events +2. We only monitor
Re: [PATCH V0 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support
On Mon, 2017-11-06 at 13:49 +0200, Alexander Shishkin wrote:
> On Fri, Nov 03, 2017 at 11:00:05AM -0700, Megha Dey wrote:
> > +static int intel_bm_event_init(struct perf_event *event)
> > +{
>
> ...
>
> > + /*
> > +* Find a hardware counter for the target task
> > +*/
> > + for (i = 0; i < bm_num_counters; i++) {
> > + if ((bm_counter_owner[i] == NULL) ||
> > + (bm_counter_owner[i]->state == PERF_EVENT_STATE_DEAD)) {
> > + counter_to_use = i;
> > + bm_counter_owner[i] = event;
> > + break;
>
> How are two concurrent perf_event_open()s not going to race here?
> Also, I'm not sure what's the value of looking at the ->state here.
> Shouldn't the ->destroy() method clear the corresponding array slot?
Yes you are right. I will add a locking mechanism here to prevent racing
and remove the ->state in the next version.
>
> > + }
> > + }
>
> ...
>
> > + wrmsrl(BR_DETECT_COUNTER_CONFIG_BASE + counter_to_use,
> > + event->hw.bm_counter_conf);
> > + wrmsrl(BR_DETECT_STATUS_MSR, 0);
>
> These wrmsrs will happen on whatever CPU perf_event_open() is called on,
> as opposed to the CPU where the event will be scheduled. You probably want
> to keep the MSR accesses in the start()/stop() callbacks.
Agreed, don't think we need this code here. We are writing to the MSRs
in start() anyways.
>
> Regards,
> --
> Alex
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V1 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support
On Mon, 2017-11-13 at 21:25 +0100, Thomas Gleixner wrote:
> On Mon, 13 Nov 2017, Dey, Megha wrote:
> > >-Original Message-
> > >From: Peter Zijlstra [mailto:pet...@infradead.org]
> > >Sent: Monday, November 13, 2017 1:00 AM
> > >To: Megha Dey <megha@linux.intel.com>
> > >Cc: x...@kernel.org; linux-ker...@vger.kernel.org; linux-
>
> Please fix your mail client so it does not add this complete useless
> information to the reply.
Will fix this.
>
> > >On Sat, Nov 11, 2017 at 01:20:05PM -0800, Megha Dey wrote:
> > >> +/*
> > >> + * Unmask the NMI bit of the local APIC the first time task is
> > >> +scheduled
> > >> + * on a particular CPU.
> > >> + */
> > >> +static void intel_bm_unmask_nmi(void) {
> > >> +this_cpu_write(bm_unmask_apic, 0);
> > >> +
> > >> +if (!(this_cpu_read(bm_unmask_apic))) {
> > >> +apic_write(APIC_LVTPC, APIC_DM_NMI);
> > >> +this_cpu_inc(bm_unmask_apic);
> > >> +}
> > >> +}
> > >
> > >What? Why?
> >
>
> > Normally, other drivers using perf create an event on every CPU (thereby
> > calling perf_init on every CPU), where this bit(APIC_DM_NMI)is explicitly
> > unmasked. In our driver, we do not do this (since we are worried only
> > about a particular task) and hence this bit is only disabled on the local
> > APIC where the perf event is initialized.
> >
> > As such, if the task is scheduled out to some other CPU, this bit is set
> > and hence would stop the interrupt from reaching the processing core.
>
> Still that code makes no sense at all and certainly does not do what you
> claim it does:
>
> > >> +this_cpu_write(bm_unmask_apic, 0);
> > >> +
> > >> +if (!(this_cpu_read(bm_unmask_apic))) {
>
> So first you write the per cpu variable to 0 and then you check whether it
> is zero, which is pointless obviously.
yes, I see your point. The logic is flawed. Will fix this.
>
> > >
> > >> +static int intel_bm_event_add(struct perf_event *event, int mode) {
>
> Please move the opening bracket of the function into the next line. See the
> kernel coding style documentation.
Will do.
>
> Thanks,
>
> tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V0 3/3] x86, bm: Add documentation on Intel Branch Monitoring
This patch adds the Documentation/x86/intel_bm.txt file with some information about Intel Branch monitoring. Signed-off-by: Megha Dey <megha@linux.intel.com> Signed-off-by: Yu-Cheng Yu <yu-cheng...@intel.com> --- Documentation/x86/intel_bm.txt | 216 + 1 file changed, 216 insertions(+) create mode 100644 Documentation/x86/intel_bm.txt diff --git a/Documentation/x86/intel_bm.txt b/Documentation/x86/intel_bm.txt new file mode 100644 index 000..25b7177 --- /dev/null +++ b/Documentation/x86/intel_bm.txt @@ -0,0 +1,216 @@ +Intel(R) Branch Monitoring + +Copyright (C) 2017 Intel Corporation + +Megha Dey <megha@intel.com> +Yu-Cheng Yu <yu-cheng...@intel.com> + +I. Overview +=== + +The Cannonlake family of Intel processors support the branch monitoring +feature. This feature uses heuristics to detect the occurrence of an ROP +(Return Oriented Programming) or ROP like(JOP:Jump oriented programming) +attack. These heuristics are based off certain performance monitoring +statistics, measured dynamically over a short configurable window period. +ROP is a malware trend in which the attacker can compromise a return +pointer held on the stack to redirect execution to a different desired +instruction. + +Support for branch monitoring has been added via Linux kernel perf event +infrastructure. This feature is enabled by CONFIG_PERF_EVENTS_INTEL_BM. + +Once the kernel is compiled with CONFIG_PERF_EVENTS_INTEL_BM=y on a +Cannonlake system, the following perf events are added which can be viewed +with perf list: + intel_bm/branch-misp/ [Kernel PMU event] + intel_bm/call-ret/ [Kernel PMU event] + intel_bm/far-branch/ [Kernel PMU event] + intel_bm/indirect-branch-misp/ [Kernel PMU event] + intel_bm/ret-misp/ [Kernel PMU event] + intel_bm/rets/ [Kernel PMU event] + +II. Hardware details + + +The MSRs associated with branch monitoring are as follows: + +1. BR_DETECT_CTRL : Branch Monitoring Global control + Used for enabling and configuring global capability + +2. BR_DETECT_STATUS : Branch Monitoring Global Status + Used by SW handler for determining detect status + +3. BR_DETECT_COUNTER_CONFIG_i : Branch Monitoring Counter Configuration + Per-cpu branch monitoring counter Configuration + +There are 2 8-bit counters that each can select between one of the +following 6 events: + +1. RET instructions: Counts the number of near return instructions retired + +2. CALL-RET instructions: Counts the difference between the number of near + return and call instructions retired + +3. RET mispredicts: Mispredicted return instructions retired + +4. Branch (all) mispredicts: Counts the number of mispredicted branches + +5. Indirect branch mispredicts: Counts the number of mispredicted indirect + near branch instructions. Includes indirect near jump/call instructions + +6. Far branch instructions: Counts the number of far branches retired + +Branch Monitoring hardware utilizes various existing performance related +counter events. Of the 6 events above, only call-ret is newly implemented. + +The events are evaluated over a specified 10-bit instruction window size +(0 to 1023). For each counter, a threshold value (0 to 127) can be +configured to set a point at which an interrupt is generated and a +detection event action is taken (determined by user-space). This can take +the form of signaling an interrupt and/or freezing the state of the last +branch record information. + +The event counters are reset after every 'window size' instructions by the +hardware. + +The feature is for user mode (privilege level > 0) operation only, which is +the known malware security threat target environment. While in supervisor +mode, this heuristic detection counter activity is suspended. This behavior +(user mode) is independent of root vs. non-root with respect to +virtualization technology execution. + +III. Software Implementation + + +A perf-based kernel driver has been used to monitor the occurrence of +one of the 6 branch monitoring events. + +If an branch monitoring interrupt is generated, the interrupt bit is set +which is cleared by interrupt handler and the event counters are reset. + +The entire system can monitor a maximum of 2 events at any given time. +These events can belong to the same or different tasks. + +Everytime a task is scheduled out, we save current window and count +associated with the event being monitored. When the task is scheduled next, +we start counting from previous count associated with this event. Thus, a +full context switch in this case is not necessary. + +The Branch Monitoring exception can be configured as a regular interrupt or +an NMI. We chain an NMI handler after PMU, because +1. It will no
[PATCH V0 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support
Currently, the cannonlake family of Intel processors support the
branch monitoring feature. Intel's Branch monitoring feature is trying
to utilize heuristics to detect the occurrence of an ROP (Return
Oriented Programming) attack.
A perf-based kernel driver has been used to monitor the occurrence of
one of the 6 branch monitoring events. There are 2 counters that each
can select between one of these events for evaluation over a specified
instruction window size (0 to 1023). For each counter, a threshold value
(0 to 127) can be configured to set a point at which ROP detection event
action is taken (determined by user-space). The entire system can monitor
a maximum of 2 events(either from the same or different tasks) at any
given time.
Apart from window_size(global) and threshold(per-counter), various sysfs
entries are provided for the user to configure: guest_disable, lbr_freeze,
window_cnt_sel, cnt_and_mode (all global) and mispred_evt_cnt(per-counter).
Everytime a task is scheduled out, we save current window and count
associated with the event being monitored. When the task is scheduled
next, we start counting from previous count associated with this event.
Thus, a full context switch in this case is not necessary.
To monitor a user space application for ROP related events, perf command
line can be used as follows:
perf stat -e
eg. For the following test program (test.c) and threshold = 100
(echo 100 > /sys/devices/intel_bm/threshold)
void func(void)
{
return;
}
void main(void)
{
int i;
for (i = 0; i < 128; i++) {
func();
}
return;
}
perf stat -e intel_bm/rets/ ./test
Performance counter stats for './test':
1 intel_bm/rets/
0.104705937 seconds time elapsed
perf returns the number of branch monitoring interrupts occurred during
the execution of the user-space application.
Signed-off-by: Megha Dey <megha@linux.intel.com>
Signed-off-by: Yu-Cheng Yu <yu-cheng...@intel.com>
---
arch/x86/events/Kconfig | 10 +
arch/x86/events/intel/Makefile | 2 +
arch/x86/events/intel/bm.c | 635 +++
arch/x86/include/asm/msr-index.h | 5 +
include/linux/perf_event.h | 8 +-
kernel/events/core.c | 8 +
6 files changed, 667 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/events/intel/bm.c
diff --git a/arch/x86/events/Kconfig b/arch/x86/events/Kconfig
index 9a7a144..40903ca 100644
--- a/arch/x86/events/Kconfig
+++ b/arch/x86/events/Kconfig
@@ -9,6 +9,16 @@ config PERF_EVENTS_INTEL_UNCORE
Include support for Intel uncore performance events. These are
available on NehalemEX and more modern processors.
+config PERF_EVENTS_INTEL_BM
+ bool "Intel Branch Monitoring support"
+ depends on PERF_EVENTS && CPU_SUP_INTEL && PCI
+ ---help---
+ Include support for Intel Branch monitoring. This feature utilizes
+ heuristics for detecting ROP(Return oriented programming) like
+ attacks. These heuristics are based off certain performance
+ monitoring statistics, measured dynamically over a short
+ configurable window period.
+
config PERF_EVENTS_INTEL_RAPL
tristate "Intel rapl performance events"
depends on PERF_EVENTS && CPU_SUP_INTEL && PCI
diff --git a/arch/x86/events/intel/Makefile b/arch/x86/events/intel/Makefile
index 3468b0c..14235ec 100644
--- a/arch/x86/events/intel/Makefile
+++ b/arch/x86/events/intel/Makefile
@@ -2,6 +2,8 @@
obj-$(CONFIG_CPU_SUP_INTEL)+= core.o bts.o
obj-$(CONFIG_CPU_SUP_INTEL)+= ds.o knc.o
obj-$(CONFIG_CPU_SUP_INTEL)+= lbr.o p4.o p6.o pt.o
+obj-$(CONFIG_PERF_EVENTS_INTEL_BM) += intel-bm-perf.o
+intel-bm-perf-objs := bm.o
obj-$(CONFIG_PERF_EVENTS_INTEL_RAPL) += intel-rapl-perf.o
intel-rapl-perf-objs := rapl.o
obj-$(CONFIG_PERF_EVENTS_INTEL_UNCORE) += intel-uncore.o
diff --git a/arch/x86/events/intel/bm.c b/arch/x86/events/intel/bm.c
new file mode 100644
index 000..79f4923
--- /dev/null
+++ b/arch/x86/events/intel/bm.c
@@ -0,0 +1,635 @@
+/*
+ * Support for Intel branch monitoring counters
+ *
+ * Intel branch monitoring MSRs are specified in the Intel® 64 and IA-32
+ * Software Developer’s Manual Volume 4 section 2.16.2 (October 2017)
+ *
+ * Copyright (c) 2017, Intel Corporation.
+ *
+ * Contact Information:
+ * Megha Dey <megha@linux.intel.com>
+ * Yu-Cheng Yu <yu-cheng...@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS
[PATCH V0 1/3] x86/cpu/intel: Add Cannonlake to Intel family
Add CPUID of Cannonlake (CNL) processors to Intel family list. Signed-off-by: Megha Dey <megha@linux.intel.com> --- arch/x86/include/asm/intel-family.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h index 35a6bc4..056bd41 100644 --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -65,6 +65,8 @@ #define INTEL_FAM6_ATOM_DENVERTON 0x5F /* Goldmont Microserver */ #define INTEL_FAM6_ATOM_GEMINI_LAKE0x7A +#define INTEL_FAM6_CANNONLAKE_MOBILE 0x66 + /* Xeon Phi */ #define INTEL_FAM6_XEON_PHI_KNL0x57 /* Knights Landing */ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V0 0/3] perf/x86/intel: Add Branch Monitoring support
This patchset adds support for Intel's branch monitoring feature. This feature uses heuristics to detect the occurrence of an ROP(Return Oriented Programming) or ROP like(JOP: Jump oriented programming) attack. These heuristics are based off certain performance monitoring statistics, measured dynamically over a short configurable window period. ROP is a malware trend in which the attacker can compromise a return pointer held on the stack to redirect execution to a different desired instruction. Currently, only the Cannonlake family of Intel processors support this feature. This feature is enabled by CONFIG_PERF_EVENTS_INTEL_BM. Once the kernel is compiled with CONFIG_PERF_EVENTS_INTEL_BM=y on a Cannonlake system, the following perf events are added which can be viewed with perf list: intel_bm/branch-misp/ [Kernel PMU event] intel_bm/call-ret/ [Kernel PMU event] intel_bm/far-branch/ [Kernel PMU event] intel_bm/indirect-branch-misp/ [Kernel PMU event] intel_bm/ret-misp/ [Kernel PMU event] intel_bm/rets/ [Kernel PMU event] A perf-based kernel driver has been used to monitor the occurrence of one of the 6 branch monitoring events. There are 2 counters that each can select between one of these events for evaluation over a specified instruction window size (0 to 1023). For each counter, a threshold value (0 to 127) can be configured to set a point at which an interrupt is generated. The entire system can monitor a maximum of 2 events(either from the same or different tasks) at any given time. Apart from the kernel driver, this patchset adds CPUID of Cannonlake processors to Intel family list and the Documentation/x86/intel_bm.txt file with some information about Intel Branch monitoring. Megha Dey (3): x86/cpu/intel: Add Cannonlake to Intel family perf/x86/intel/bm.c: Add Intel Branch Monitoring support x86, bm: Add documentation on Intel Branch Monitoring Documentation/x86/intel_bm.txt | 216 arch/x86/events/Kconfig | 10 + arch/x86/events/intel/Makefile | 2 + arch/x86/events/intel/bm.c | 635 arch/x86/include/asm/intel-family.h | 2 + arch/x86/include/asm/msr-index.h| 5 + include/linux/perf_event.h | 8 +- kernel/events/core.c| 8 + 8 files changed, 885 insertions(+), 1 deletion(-) create mode 100644 Documentation/x86/intel_bm.txt create mode 100644 arch/x86/events/intel/bm.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support
On Wed, 2017-12-13 at 08:21 +0100, Peter Zijlstra wrote: > On Tue, Dec 12, 2017 at 03:08:00PM -0800, Megha Dey wrote: > > > > > > There's work on the way to allow multiple HW PMUs. You'll either have to > > > wait for that or help in making that happen. What you do not do is > > > silently hack around it. > > > > Could I get a pointer to the code implementing this? > > > > There isn't much code now; but it could be build on top of the stuff > here: > > git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core > > It was mostly Mark I think who wanted this for big litte stuffs. Could you give us an estimate on the amount of time it could take to implement this? I am not sure what the current status is or if Mark has been working on it. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support
On Wed, 2017-12-20 at 13:23 -0800, Megha Dey wrote: > On Wed, 2017-12-13 at 08:21 +0100, Peter Zijlstra wrote: > > On Tue, Dec 12, 2017 at 03:08:00PM -0800, Megha Dey wrote: > > > > > > > > There's work on the way to allow multiple HW PMUs. You'll either have to > > > > wait for that or help in making that happen. What you do not do is > > > > silently hack around it. > > > > > > Could I get a pointer to the code implementing this? > > > > > > > There isn't much code now; but it could be build on top of the stuff > > here: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core > > > > It was mostly Mark I think who wanted this for big litte stuffs. > > Could you give us an estimate on the amount of time it could take to > implement this? > > I am not sure what the current status is or if Mark has been working on > it. > Hi Peter, Is there anyone currently working on this? -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
