* [PATCH v1 0/5] perf kvm: Add stat support on arm64
@ 2019-06-12 9:08 Zenghui Yu
2019-06-12 9:08 ` [PATCH v1 1/5] KVM: arm/arm64: Remove kvm_mmio_emulate tracepoint Zenghui Yu
` (4 more replies)
0 siblings, 5 replies; 12+ messages in thread
From: Zenghui Yu @ 2019-06-12 9:08 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm, linux-kernel, linux-perf-users
Cc: mark.rutland, marc.zyngier, catalin.marinas, will.deacon,
christoffer.dall, acme, linuxarm, acme, peterz,
alexander.shishkin, mingo, wanghaibin.wang, ganapatrao.kulkarni,
Zenghui Yu, namhyung, jolsa, xiexiangyou
'perf kvm stat report/record' generates a statistical analysis of KVM
events and can be used to analyze guest exit reasons. This series tries
to add stat support on arm64 (Port perf-kvm-stat to arm64 - this is
already supported on x86).
"record" enables recording of two pair of tracepoints:
- "kvm:kvm_entry" and "kvm:kvm_exit"
- "kvm:kvm_trap_enter" and "kvm:kvm_trap_exit"
"report" reports statistical analysis of guest exit&trap events.
To record kvm events on the host:
# perf kvm stat record -a
To report kvm VM EXIT events:
# perf kvm stat report --event=vmexit
To report kvm VM TRAP (synchronous exceptions) events:
# perf kvm stat report --event=trap
More information can be found at tools/perf/Documentation/perf-kvm.txt.
* Patch 1-2 touch KVM/ARM side, with #1 is cleanup and #2 is preparation
for perf-kvm-stat support.
* Patch 3-5 touch perf side.
* Patch 3 adds support for get_cpuid() function on arm64. *RFC!*
* Patch 4 adds support for perf-kvm-stat on arm64, with VM-EXIT events.
* Patch 5 adds support to report TRAP-EVENT events.
Any suggestions, comments and test results will be appreciated.
Thanks,
zenghui
---
Zenghui Yu (5):
KVM: arm/arm64: Remove kvm_mmio_emulate tracepoint
KVM: arm/arm64: Adjust entry/exit and trap related tracepoints
perf tools arm64: Add support for get_cpuid() function
perf,kvm/arm64: Add stat support on arm64
perf,kvm/arm64: perf-kvm-stat to report VM TRAP
arch/arm64/kvm/handle_exit.c | 3 +
arch/arm64/kvm/trace.h | 35 +++++++
tools/perf/arch/arm64/Makefile | 2 +
tools/perf/arch/arm64/util/Build | 1 +
tools/perf/arch/arm64/util/aarch64_guest_exits.h | 91 +++++++++++++++++
tools/perf/arch/arm64/util/header.c | 74 +++++++++-----
tools/perf/arch/arm64/util/kvm-stat.c | 125 +++++++++++++++++++++++
virt/kvm/arm/arm.c | 4 +-
virt/kvm/arm/trace.h | 42 ++------
9 files changed, 317 insertions(+), 60 deletions(-)
create mode 100644 tools/perf/arch/arm64/util/aarch64_guest_exits.h
create mode 100644 tools/perf/arch/arm64/util/kvm-stat.c
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v1 1/5] KVM: arm/arm64: Remove kvm_mmio_emulate tracepoint
2019-06-12 9:08 [PATCH v1 0/5] perf kvm: Add stat support on arm64 Zenghui Yu
@ 2019-06-12 9:08 ` Zenghui Yu
2019-06-12 12:48 ` James Morse
2019-06-12 9:08 ` [PATCH v1 2/5] KVM: arm/arm64: Adjust entry/exit and trap related tracepoints Zenghui Yu
` (3 subsequent siblings)
4 siblings, 1 reply; 12+ messages in thread
From: Zenghui Yu @ 2019-06-12 9:08 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm, linux-kernel, linux-perf-users
Cc: mark.rutland, marc.zyngier, catalin.marinas, will.deacon,
christoffer.dall, acme, linuxarm, acme, peterz,
alexander.shishkin, mingo, wanghaibin.wang, ganapatrao.kulkarni,
Zenghui Yu, namhyung, jolsa, xiexiangyou
In current KVM/ARM code, no one will invoke trace_kvm_mmio_emulate().
Remove this TRACE_EVENT definition.
Cc: Christoffer Dall <christoffer.dall@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
---
virt/kvm/arm/trace.h | 21 ---------------------
1 file changed, 21 deletions(-)
diff --git a/virt/kvm/arm/trace.h b/virt/kvm/arm/trace.h
index 204d210..8b7dff2 100644
--- a/virt/kvm/arm/trace.h
+++ b/virt/kvm/arm/trace.h
@@ -114,27 +114,6 @@
__entry->type, __entry->vcpu_idx, __entry->irq_num, __entry->level)
);
-TRACE_EVENT(kvm_mmio_emulate,
- TP_PROTO(unsigned long vcpu_pc, unsigned long instr,
- unsigned long cpsr),
- TP_ARGS(vcpu_pc, instr, cpsr),
-
- TP_STRUCT__entry(
- __field( unsigned long, vcpu_pc )
- __field( unsigned long, instr )
- __field( unsigned long, cpsr )
- ),
-
- TP_fast_assign(
- __entry->vcpu_pc = vcpu_pc;
- __entry->instr = instr;
- __entry->cpsr = cpsr;
- ),
-
- TP_printk("Emulate MMIO at: 0x%08lx (instr: %08lx, cpsr: %08lx)",
- __entry->vcpu_pc, __entry->instr, __entry->cpsr)
-);
-
TRACE_EVENT(kvm_unmap_hva_range,
TP_PROTO(unsigned long start, unsigned long end),
TP_ARGS(start, end),
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v1 2/5] KVM: arm/arm64: Adjust entry/exit and trap related tracepoints
2019-06-12 9:08 [PATCH v1 0/5] perf kvm: Add stat support on arm64 Zenghui Yu
2019-06-12 9:08 ` [PATCH v1 1/5] KVM: arm/arm64: Remove kvm_mmio_emulate tracepoint Zenghui Yu
@ 2019-06-12 9:08 ` Zenghui Yu
2019-06-12 12:49 ` James Morse
2019-06-12 9:08 ` [PATCH v1 3/5] perf tools arm64: Add support for get_cpuid() function Zenghui Yu
` (2 subsequent siblings)
4 siblings, 1 reply; 12+ messages in thread
From: Zenghui Yu @ 2019-06-12 9:08 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm, linux-kernel, linux-perf-users
Cc: mark.rutland, marc.zyngier, catalin.marinas, will.deacon,
christoffer.dall, acme, linuxarm, acme, peterz,
alexander.shishkin, mingo, wanghaibin.wang, ganapatrao.kulkarni,
Zenghui Yu, namhyung, jolsa, xiexiangyou
Currently, we use trace_kvm_exit() to report exception type (e.g.,
"IRQ", "TRAP") and exception class (ESR_ELx's bit[31:26]) together.
But hardware only saves the exit class to ESR_ELx on synchronous
exceptions, not on asynchronous exceptions. When the guest exits
due to external interrupts, we will get tracing output like:
"kvm_exit: IRQ: HSR_EC: 0x0000 (UNKNOWN), PC: 0xffff87259e30"
Obviously, "HSR_EC" here is meaningless.
This patch splits "exit" and "trap" events by adding two tracepoints
explicitly in handle_trap_exceptions(). Let trace_kvm_exit() report VM
exit events, and trace_kvm_trap_exit() report VM trap events.
These tracepoints are adjusted also in preparation for supporting
'perf kvm stat' on arm64.
Cc: Christoffer Dall <christoffer.dall@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
---
arch/arm64/kvm/handle_exit.c | 3 +++
arch/arm64/kvm/trace.h | 35 +++++++++++++++++++++++++++++++++++
virt/kvm/arm/arm.c | 4 ++--
virt/kvm/arm/trace.h | 21 +++++++++++----------
4 files changed, 51 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 516aead..af3c732 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -264,7 +264,10 @@ static int handle_trap_exceptions(struct kvm_vcpu *vcpu, struct kvm_run *run)
exit_handle_fn exit_handler;
exit_handler = kvm_get_exit_handler(vcpu);
+ trace_kvm_trap_enter(vcpu->vcpu_id,
+ kvm_vcpu_trap_get_class(vcpu));
handled = exit_handler(vcpu, run);
+ trace_kvm_trap_exit(vcpu->vcpu_id);
}
return handled;
diff --git a/arch/arm64/kvm/trace.h b/arch/arm64/kvm/trace.h
index eab91ad..6014c73 100644
--- a/arch/arm64/kvm/trace.h
+++ b/arch/arm64/kvm/trace.h
@@ -8,6 +8,41 @@
#undef TRACE_SYSTEM
#define TRACE_SYSTEM kvm
+TRACE_EVENT(kvm_trap_enter,
+ TP_PROTO(unsigned int vcpu_id, unsigned int esr_ec),
+ TP_ARGS(vcpu_id, esr_ec),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, vcpu_id)
+ __field(unsigned int, esr_ec)
+ ),
+
+ TP_fast_assign(
+ __entry->vcpu_id = vcpu_id;
+ __entry->esr_ec = esr_ec;
+ ),
+
+ TP_printk("VCPU %u: HSR_EC=0x%04x (%s)",
+ __entry->vcpu_id,
+ __entry->esr_ec,
+ __print_symbolic(__entry->esr_ec, kvm_arm_exception_class))
+);
+
+TRACE_EVENT(kvm_trap_exit,
+ TP_PROTO(unsigned int vcpu_id),
+ TP_ARGS(vcpu_id),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, vcpu_id)
+ ),
+
+ TP_fast_assign(
+ __entry->vcpu_id = vcpu_id;
+ ),
+
+ TP_printk("VCPU %u", __entry->vcpu_id)
+);
+
TRACE_EVENT(kvm_wfx_arm64,
TP_PROTO(unsigned long vcpu_pc, bool is_wfe),
TP_ARGS(vcpu_pc, is_wfe),
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index 90cedeb..9f63fd9 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -758,7 +758,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
/**************************************************************
* Enter the guest
*/
- trace_kvm_entry(*vcpu_pc(vcpu));
+ trace_kvm_entry(vcpu->vcpu_id, *vcpu_pc(vcpu));
guest_enter_irqoff();
if (has_vhe()) {
@@ -822,7 +822,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
* guest time.
*/
guest_exit();
- trace_kvm_exit(ret, kvm_vcpu_trap_get_class(vcpu), *vcpu_pc(vcpu));
+ trace_kvm_exit(vcpu->vcpu_id, ret, *vcpu_pc(vcpu));
/* Exit types that need handling before we can be preempted */
handle_exit_early(vcpu, run, ret);
diff --git a/virt/kvm/arm/trace.h b/virt/kvm/arm/trace.h
index 8b7dff2..edd9dae 100644
--- a/virt/kvm/arm/trace.h
+++ b/virt/kvm/arm/trace.h
@@ -12,40 +12,41 @@
* Tracepoints for entry/exit to guest
*/
TRACE_EVENT(kvm_entry,
- TP_PROTO(unsigned long vcpu_pc),
- TP_ARGS(vcpu_pc),
+ TP_PROTO(unsigned int vcpu_id, unsigned long vcpu_pc),
+ TP_ARGS(vcpu_id, vcpu_pc),
TP_STRUCT__entry(
+ __field( unsigned int, vcpu_id )
__field( unsigned long, vcpu_pc )
),
TP_fast_assign(
+ __entry->vcpu_id = vcpu_id;
__entry->vcpu_pc = vcpu_pc;
),
- TP_printk("PC: 0x%08lx", __entry->vcpu_pc)
+ TP_printk("VCPU %u: PC=0x%08lx", __entry->vcpu_id, __entry->vcpu_pc)
);
TRACE_EVENT(kvm_exit,
- TP_PROTO(int ret, unsigned int esr_ec, unsigned long vcpu_pc),
- TP_ARGS(ret, esr_ec, vcpu_pc),
+ TP_PROTO(unsigned int vcpu_id, int ret, unsigned long vcpu_pc),
+ TP_ARGS(vcpu_id, ret, vcpu_pc),
TP_STRUCT__entry(
+ __field( unsigned int, vcpu_id )
__field( int, ret )
- __field( unsigned int, esr_ec )
__field( unsigned long, vcpu_pc )
),
TP_fast_assign(
+ __entry->vcpu_id = vcpu_id;
__entry->ret = ARM_EXCEPTION_CODE(ret);
- __entry->esr_ec = ARM_EXCEPTION_IS_TRAP(ret) ? esr_ec : 0;
__entry->vcpu_pc = vcpu_pc;
),
- TP_printk("%s: HSR_EC: 0x%04x (%s), PC: 0x%08lx",
+ TP_printk("VCPU %u: exit_type=%s, PC=0x%08lx",
+ __entry->vcpu_id,
__print_symbolic(__entry->ret, kvm_arm_exception_type),
- __entry->esr_ec,
- __print_symbolic(__entry->esr_ec, kvm_arm_exception_class),
__entry->vcpu_pc)
);
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v1 3/5] perf tools arm64: Add support for get_cpuid() function
2019-06-12 9:08 [PATCH v1 0/5] perf kvm: Add stat support on arm64 Zenghui Yu
2019-06-12 9:08 ` [PATCH v1 1/5] KVM: arm/arm64: Remove kvm_mmio_emulate tracepoint Zenghui Yu
2019-06-12 9:08 ` [PATCH v1 2/5] KVM: arm/arm64: Adjust entry/exit and trap related tracepoints Zenghui Yu
@ 2019-06-12 9:08 ` Zenghui Yu
2019-06-12 9:08 ` [PATCH v1 4/5] perf,kvm/arm64: Add stat support on arm64 Zenghui Yu
2019-06-12 9:08 ` [PATCH v1 5/5] perf,kvm/arm64: perf-kvm-stat to report VM TRAP Zenghui Yu
4 siblings, 0 replies; 12+ messages in thread
From: Zenghui Yu @ 2019-06-12 9:08 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm, linux-kernel, linux-perf-users
Cc: mark.rutland, marc.zyngier, catalin.marinas, will.deacon,
christoffer.dall, acme, linuxarm, acme, peterz,
alexander.shishkin, mingo, wanghaibin.wang, ganapatrao.kulkarni,
Zenghui Yu, namhyung, jolsa, xiexiangyou
The get_cpuid() function returns the MIDR string of the first CPU.
Cc: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
---
When recording, perf will write host's cpuid (through get_cpuid()) into
perf.data.guest file:
__cmd_record
record__finish_output
perf_session__write_header
perf_header__adds_write
do_write_feat (type == HEADER_CPUID)
write_cpuid
When reporting, perf will read cpuid from perf.data.guest file:
read_events
perf_session__new
perf_session__open
perf_session__read_header
perf_header__process_sections
perf_file_section__process
process_cpuid
I'm not familiar with ARM ID register usage, and how does perf code make
use of get_cpuid() function. If we left get_cpuid() unimplemented on
arm64 (we have a default implementation in tools/perf/util/header.c),
'perf kvm stat report' will failed with following error:
"Failed to look up CPU type"
I will read the code further, and any comments or suggestions from both
sides (arm64 & perf) will be appreciated.
---
| 74 +++++++++++++++++++++++--------------
1 file changed, 47 insertions(+), 27 deletions(-)
--git a/tools/perf/arch/arm64/util/header.c b/tools/perf/arch/arm64/util/header.c
index 534cd25..5c17b86 100644
--- a/tools/perf/arch/arm64/util/header.c
+++ b/tools/perf/arch/arm64/util/header.c
@@ -9,17 +9,56 @@
#define MIDR_VARIANT_SHIFT 20
#define MIDR_VARIANT_MASK (0xf << MIDR_VARIANT_SHIFT)
-char *get_cpuid_str(struct perf_pmu *pmu)
+/* Return value of midr_el1 if success, else return 0. */
+static int read_midr_el1(char *buf, int cpu_nr)
{
- char *buf = NULL;
char path[PATH_MAX];
const char *sysfs = sysfs__mountpoint();
+ u64 midr = 0;
+ FILE *file;
+
+ if (!sysfs)
+ return 0;
+
+ scnprintf(path, PATH_MAX, "%s/devices/system/cpu/cpu%d"MIDR,
+ sysfs, cpu_nr);
+
+ file = fopen(path, "r");
+ if (!file) {
+ pr_debug("fopen failed for file %s\n", path);
+ return 0;
+ }
+
+ if (!fgets(buf, MIDR_SIZE, file)) {
+ fclose(file);
+ return 0;
+ }
+ fclose(file);
+
+ /* Ignore/clear Variant[23:20] and Revision[3:0] of MIDR */
+ midr = strtoul(buf, NULL, 16);
+ midr &= (~(MIDR_VARIANT_MASK | MIDR_REVISION_MASK));
+ scnprintf(buf, MIDR_SIZE, "0x%016lx", midr);
+
+ return midr;
+}
+
+int get_cpuid(char *buffer, size_t sz __maybe_unused)
+{
+ if (read_midr_el1(buffer, 0))
+ return 0;
+
+ return -1;
+}
+
+char *get_cpuid_str(struct perf_pmu *pmu)
+{
+ char *buf = NULL;
int cpu;
u64 midr = 0;
struct cpu_map *cpus;
- FILE *file;
- if (!sysfs || !pmu || !pmu->cpus)
+ if (!pmu || !pmu->cpus)
return NULL;
buf = malloc(MIDR_SIZE);
@@ -29,29 +68,10 @@ char *get_cpuid_str(struct perf_pmu *pmu)
/* read midr from list of cpus mapped to this pmu */
cpus = cpu_map__get(pmu->cpus);
for (cpu = 0; cpu < cpus->nr; cpu++) {
- scnprintf(path, PATH_MAX, "%s/devices/system/cpu/cpu%d"MIDR,
- sysfs, cpus->map[cpu]);
-
- file = fopen(path, "r");
- if (!file) {
- pr_debug("fopen failed for file %s\n", path);
- continue;
- }
-
- if (!fgets(buf, MIDR_SIZE, file)) {
- fclose(file);
- continue;
- }
- fclose(file);
-
- /* Ignore/clear Variant[23:20] and
- * Revision[3:0] of MIDR
- */
- midr = strtoul(buf, NULL, 16);
- midr &= (~(MIDR_VARIANT_MASK | MIDR_REVISION_MASK));
- scnprintf(buf, MIDR_SIZE, "0x%016lx", midr);
- /* got midr break loop */
- break;
+ midr = read_midr_el1(buf, cpus->map[cpu]);
+ if (midr)
+ /* got midr break loop */
+ break;
}
if (!midr) {
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v1 4/5] perf,kvm/arm64: Add stat support on arm64
2019-06-12 9:08 [PATCH v1 0/5] perf kvm: Add stat support on arm64 Zenghui Yu
` (2 preceding siblings ...)
2019-06-12 9:08 ` [PATCH v1 3/5] perf tools arm64: Add support for get_cpuid() function Zenghui Yu
@ 2019-06-12 9:08 ` Zenghui Yu
2019-06-12 9:08 ` [PATCH v1 5/5] perf,kvm/arm64: perf-kvm-stat to report VM TRAP Zenghui Yu
4 siblings, 0 replies; 12+ messages in thread
From: Zenghui Yu @ 2019-06-12 9:08 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm, linux-kernel, linux-perf-users
Cc: mark.rutland, marc.zyngier, catalin.marinas, will.deacon,
christoffer.dall, acme, linuxarm, acme, peterz,
alexander.shishkin, mingo, wanghaibin.wang, ganapatrao.kulkarni,
Zenghui Yu, namhyung, jolsa, xiexiangyou
'perf kvm stat report/record' generates a statistical analysis of KVM
events and can be used to analyze guest exit reasons. This patch tries
to add stat support on arm64.
We have a mapping between guest's "exit_code" and "exit_reason" which
already exists under arch/arm64/include/asm/ (kvm_arm_exception_type),
and we've used it to report guest's exit type through trace_kvm_exit().
Copy kvm_arm_exception_type into aarch64_guest_exits.h, thus export it
to userspace.
It records on two available KVM tracepoints for arm64: "kvm:kvm_entry"
and "kvm:kvm_exit", and reports statistical data which includes events
handles time, samples, and so on.
A simple test go below:
# pgrep qemu
6039
9937
# ./tools/perf/perf kvm stat record -p 6039
[ perf record: Woken up 3 times to write data ]
[ perf record: Captured and wrote 15.629 MB perf.data.guest (199063 samples) ]
# ./tools/perf/perf kvm stat report --event=vmexit
Analyze events for all VMs, all VCPUs:
VM-EXIT Samples Samples% Time% Min Time Max Time Avg time
TRAP 49040 97.15% 100.00% 2.60us 4072.98us 3431.60us ( +- 0.17% )
IRQ 1437 2.85% 0.00% 0.90us 24.56us 2.06us ( +- 1.37% )
Total Samples:50477, Total events handled time:168288630.04us.
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Christoffer Dall <christoffer.dall@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
---
tools/perf/arch/arm64/Makefile | 2 +
tools/perf/arch/arm64/util/Build | 1 +
tools/perf/arch/arm64/util/aarch64_guest_exits.h | 23 +++++++++
tools/perf/arch/arm64/util/kvm-stat.c | 60 ++++++++++++++++++++++++
4 files changed, 86 insertions(+)
create mode 100644 tools/perf/arch/arm64/util/aarch64_guest_exits.h
create mode 100644 tools/perf/arch/arm64/util/kvm-stat.c
diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
index dbef716..172146e 100644
--- a/tools/perf/arch/arm64/Makefile
+++ b/tools/perf/arch/arm64/Makefile
@@ -2,6 +2,8 @@
ifndef NO_DWARF
PERF_HAVE_DWARF_REGS := 1
endif
+
+HAVE_KVM_STAT_SUPPORT := 1
PERF_HAVE_JITDUMP := 1
PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
diff --git a/tools/perf/arch/arm64/util/Build b/tools/perf/arch/arm64/util/Build
index 3cde540..d136674 100644
--- a/tools/perf/arch/arm64/util/Build
+++ b/tools/perf/arch/arm64/util/Build
@@ -1,5 +1,6 @@
perf-y += header.o
perf-y += sym-handling.o
+perf-y += kvm-stat.o
perf-$(CONFIG_DWARF) += dwarf-regs.o
perf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o
perf-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o
diff --git a/tools/perf/arch/arm64/util/aarch64_guest_exits.h b/tools/perf/arch/arm64/util/aarch64_guest_exits.h
new file mode 100644
index 0000000..a8ca4b8
--- /dev/null
+++ b/tools/perf/arch/arm64/util/aarch64_guest_exits.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef ARCH_PERF_AARCH64_GUEST_EXITS_H
+#define ARCH_PERF_AARCH64_GUEST_EXITS_H
+
+/* virt.h */
+/* Error returned when an invalid stub number is passed into x0 */
+#define HVC_STUB_ERR 0xbadca11
+
+/* kvm_asm.h */
+#define ARM_EXCEPTION_IRQ 0
+#define ARM_EXCEPTION_EL1_SERROR 1
+#define ARM_EXCEPTION_TRAP 2
+#define ARM_EXCEPTION_IL 3
+/* The hyp-stub will return this for any kvm_call_hyp() call */
+#define ARM_EXCEPTION_HYP_GONE HVC_STUB_ERR
+
+#define kvm_arm_exception_type \
+ {ARM_EXCEPTION_IRQ, "IRQ" }, \
+ {ARM_EXCEPTION_EL1_SERROR, "SERROR" }, \
+ {ARM_EXCEPTION_TRAP, "TRAP" }, \
+ {ARM_EXCEPTION_HYP_GONE, "HYP_GONE" }
+
+#endif
diff --git a/tools/perf/arch/arm64/util/kvm-stat.c b/tools/perf/arch/arm64/util/kvm-stat.c
new file mode 100644
index 0000000..5804bc2
--- /dev/null
+++ b/tools/perf/arch/arm64/util/kvm-stat.c
@@ -0,0 +1,60 @@
+/*
+ * Arch specific functions for perf kvm stat.
+ *
+ * Copyright (c) 2019 - Huawei Technologies Co., Ltd.
+ * Author(s): Zenghui Yu <yuzenghui@huawei.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+#include <errno.h>
+#include "../../util/kvm-stat.h"
+#include "../../util/evsel.h"
+#include "aarch64_guest_exits.h"
+
+define_exit_reasons_table(arm64_exit_reasons, kvm_arm_exception_type);
+
+static struct kvm_events_ops exit_events = {
+ .is_begin_event = exit_event_begin,
+ .is_end_event = exit_event_end,
+ .decode_key = exit_event_decode_key,
+ .name = "VM-EXIT"
+};
+
+const char *vcpu_id_str = "vcpu_id";
+const int decode_str_len = 20;
+const char *kvm_exit_reason = "ret";
+const char *kvm_entry_trace = "kvm:kvm_entry";
+const char *kvm_exit_trace = "kvm:kvm_exit";
+
+const char *kvm_events_tp[] = {
+ "kvm:kvm_entry",
+ "kvm:kvm_exit",
+ NULL,
+};
+
+struct kvm_reg_events_ops kvm_reg_events_ops[] = {
+ { .name = "vmexit", .ops = &exit_events },
+ { NULL, NULL },
+};
+
+const char * const kvm_skip_events[] = {
+ NULL,
+};
+
+int cpu_isa_init(struct perf_kvm_stat *kvm, const char *cpuid __maybe_unused)
+{
+ kvm->exit_reasons = arm64_exit_reasons;
+ kvm->exit_reasons_isa = "aarch64";
+
+ return 0;
+}
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v1 5/5] perf,kvm/arm64: perf-kvm-stat to report VM TRAP
2019-06-12 9:08 [PATCH v1 0/5] perf kvm: Add stat support on arm64 Zenghui Yu
` (3 preceding siblings ...)
2019-06-12 9:08 ` [PATCH v1 4/5] perf,kvm/arm64: Add stat support on arm64 Zenghui Yu
@ 2019-06-12 9:08 ` Zenghui Yu
4 siblings, 0 replies; 12+ messages in thread
From: Zenghui Yu @ 2019-06-12 9:08 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm, linux-kernel, linux-perf-users
Cc: mark.rutland, marc.zyngier, catalin.marinas, will.deacon,
christoffer.dall, acme, linuxarm, acme, peterz,
alexander.shishkin, mingo, wanghaibin.wang, ganapatrao.kulkarni,
Zenghui Yu, namhyung, jolsa, xiexiangyou
When guest exits due to "TRAP", we can analyze the guest exit reasons
deeplier. Enhance perf-kvm-stat to record and analyze VM TRAP events.
There is a mapping between guest's "trap_code" (ESR_ELx's bits[31:26])
and "trap_reason" - kvm_arm_exception_class. Copy it from kernel to
aarch64_guest_exits.h, export it to userspace.
This patch records two new KVM tracepoints: "kvm:kvm_trap_enter" and
"kvm:kvm_trap_exit", and reports statistical data between these two
tracepoints.
A simple test go below:
# ./tools/perf/perf kvm stat record -p 20763
[ perf record: Woken up 92 times to write data ]
[ perf record: Captured and wrote 203.727 MB perf.data.guest (2601786 samples) ]
# ./tools/perf/perf kvm stat report --event=vmexit
Analyze events for all VMs, all VCPUs:
VM-EXIT Samples Samples% Time% Min Time Max Time Avg time
TRAP 640931 97.12% 100.00% 2.44us 14683.86us 3446.49us ( +- 0.05% )
IRQ 19019 2.88% 0.00% 0.90us 461.94us 2.12us ( +- 2.09% )
Total Samples:659950, Total events handled time:2209005391.30us.
# ./tools/perf/perf kvm stat report --event=trap
Analyze events for all VMs, all VCPUs:
TRAP-EVENT Samples Samples% Time% Min Time Max Time Avg time
WFx 601194 93.80% 99.98% 0.90us 4294.04us 3671.01us ( +- 0.03% )
SYS64 33714 5.26% 0.01% 1.10us 41.34us 5.68us ( +- 0.18% )
DABT_LOW 6014 0.94% 0.00% 1.12us 18.04us 2.57us ( +- 0.91% )
IABT_LOW 12 0.00% 0.01% 12597.76us 14679.96us 12893.61us ( +- 1.34% )
Total Samples:640934, Total events handled time:2207353434.56us.
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Christoffer Dall <christoffer.dall@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
---
tools/perf/arch/arm64/util/aarch64_guest_exits.h | 68 ++++++++++++++++++++++++
tools/perf/arch/arm64/util/kvm-stat.c | 65 ++++++++++++++++++++++
2 files changed, 133 insertions(+)
diff --git a/tools/perf/arch/arm64/util/aarch64_guest_exits.h b/tools/perf/arch/arm64/util/aarch64_guest_exits.h
index a8ca4b8..0dbbd87 100644
--- a/tools/perf/arch/arm64/util/aarch64_guest_exits.h
+++ b/tools/perf/arch/arm64/util/aarch64_guest_exits.h
@@ -20,4 +20,72 @@
{ARM_EXCEPTION_TRAP, "TRAP" }, \
{ARM_EXCEPTION_HYP_GONE, "HYP_GONE" }
+/* esr.h */
+#define ESR_ELx_EC_UNKNOWN (0x00)
+#define ESR_ELx_EC_WFx (0x01)
+/* Unallocated EC: 0x02 */
+#define ESR_ELx_EC_CP15_32 (0x03)
+#define ESR_ELx_EC_CP15_64 (0x04)
+#define ESR_ELx_EC_CP14_MR (0x05)
+#define ESR_ELx_EC_CP14_LS (0x06)
+#define ESR_ELx_EC_FP_ASIMD (0x07)
+#define ESR_ELx_EC_CP10_ID (0x08) /* EL2 only */
+#define ESR_ELx_EC_PAC (0x09) /* EL2 and above */
+/* Unallocated EC: 0x0A - 0x0B */
+#define ESR_ELx_EC_CP14_64 (0x0C)
+/* Unallocated EC: 0x0d */
+#define ESR_ELx_EC_ILL (0x0E)
+/* Unallocated EC: 0x0F - 0x10 */
+#define ESR_ELx_EC_SVC32 (0x11)
+#define ESR_ELx_EC_HVC32 (0x12) /* EL2 only */
+#define ESR_ELx_EC_SMC32 (0x13) /* EL2 and above */
+/* Unallocated EC: 0x14 */
+#define ESR_ELx_EC_SVC64 (0x15)
+#define ESR_ELx_EC_HVC64 (0x16) /* EL2 and above */
+#define ESR_ELx_EC_SMC64 (0x17) /* EL2 and above */
+#define ESR_ELx_EC_SYS64 (0x18)
+#define ESR_ELx_EC_SVE (0x19)
+/* Unallocated EC: 0x1A - 0x1E */
+#define ESR_ELx_EC_IMP_DEF (0x1f) /* EL3 only */
+#define ESR_ELx_EC_IABT_LOW (0x20)
+#define ESR_ELx_EC_IABT_CUR (0x21)
+#define ESR_ELx_EC_PC_ALIGN (0x22)
+/* Unallocated EC: 0x23 */
+#define ESR_ELx_EC_DABT_LOW (0x24)
+#define ESR_ELx_EC_DABT_CUR (0x25)
+#define ESR_ELx_EC_SP_ALIGN (0x26)
+/* Unallocated EC: 0x27 */
+#define ESR_ELx_EC_FP_EXC32 (0x28)
+/* Unallocated EC: 0x29 - 0x2B */
+#define ESR_ELx_EC_FP_EXC64 (0x2C)
+/* Unallocated EC: 0x2D - 0x2E */
+#define ESR_ELx_EC_SERROR (0x2F)
+#define ESR_ELx_EC_BREAKPT_LOW (0x30)
+#define ESR_ELx_EC_BREAKPT_CUR (0x31)
+#define ESR_ELx_EC_SOFTSTP_LOW (0x32)
+#define ESR_ELx_EC_SOFTSTP_CUR (0x33)
+#define ESR_ELx_EC_WATCHPT_LOW (0x34)
+#define ESR_ELx_EC_WATCHPT_CUR (0x35)
+/* Unallocated EC: 0x36 - 0x37 */
+#define ESR_ELx_EC_BKPT32 (0x38)
+/* Unallocated EC: 0x39 */
+#define ESR_ELx_EC_VECTOR32 (0x3A) /* EL2 only */
+/* Unallocted EC: 0x3B */
+#define ESR_ELx_EC_BRK64 (0x3C)
+/* Unallocated EC: 0x3D - 0x3F */
+#define ESR_ELx_EC_MAX (0x3F)
+
+/* kvm_arm.h */
+#define ECN(x) { ESR_ELx_EC_##x, #x }
+
+#define kvm_arm_exception_class \
+ ECN(UNKNOWN), ECN(WFx), ECN(CP15_32), ECN(CP15_64), ECN(CP14_MR), \
+ ECN(CP14_LS), ECN(FP_ASIMD), ECN(CP10_ID), ECN(CP14_64), ECN(SVC64), \
+ ECN(HVC64), ECN(SMC64), ECN(SYS64), ECN(IMP_DEF), ECN(IABT_LOW), \
+ ECN(IABT_CUR), ECN(PC_ALIGN), ECN(DABT_LOW), ECN(DABT_CUR), \
+ ECN(SP_ALIGN), ECN(FP_EXC32), ECN(FP_EXC64), ECN(SERROR), \
+ ECN(BREAKPT_LOW), ECN(BREAKPT_CUR), ECN(SOFTSTP_LOW), \
+ ECN(SOFTSTP_CUR), ECN(WATCHPT_LOW), ECN(WATCHPT_CUR), \
+ ECN(BKPT32), ECN(VECTOR32), ECN(BRK64)
+
#endif
diff --git a/tools/perf/arch/arm64/util/kvm-stat.c b/tools/perf/arch/arm64/util/kvm-stat.c
index 5804bc2..afa0fc5 100644
--- a/tools/perf/arch/arm64/util/kvm-stat.c
+++ b/tools/perf/arch/arm64/util/kvm-stat.c
@@ -22,6 +22,7 @@
#include "aarch64_guest_exits.h"
define_exit_reasons_table(arm64_exit_reasons, kvm_arm_exception_type);
+define_exit_reasons_table(arm64_trap_reasons, kvm_arm_exception_class);
static struct kvm_events_ops exit_events = {
.is_begin_event = exit_event_begin,
@@ -36,14 +37,78 @@
const char *kvm_entry_trace = "kvm:kvm_entry";
const char *kvm_exit_trace = "kvm:kvm_exit";
+const char *kvm_trap_reason = "esr_ec";
+const char *kvm_trap_enter_trace = "kvm:kvm_trap_enter";
+const char *kvm_trap_exit_trace = "kvm:kvm_trap_exit";
+
+static void trap_event_get_key(struct perf_evsel *evsel,
+ struct perf_sample *sample,
+ struct event_key *key)
+{
+ key->info = 0;
+ key->key = perf_evsel__intval(evsel, sample, kvm_trap_reason);
+}
+
+static const char *get_trap_reason(u64 exit_code)
+{
+ struct exit_reasons_table *tbl = arm64_trap_reasons;
+
+ while (tbl->reason != NULL) {
+ if (tbl->exit_code == exit_code)
+ return tbl->reason;
+ tbl++;
+ }
+
+ pr_err("Unknown kvm trap exit code: %lld on aarch64\n",
+ (unsigned long long)exit_code);
+ return "UNKNOWN";
+}
+
+static bool trap_event_begin(struct perf_evsel *evsel,
+ struct perf_sample *sample, struct event_key *key)
+{
+ if (!strcmp(evsel->name, kvm_trap_enter_trace)) {
+ trap_event_get_key(evsel, sample, key);
+ return true;
+ }
+
+ return false;
+}
+
+static bool trap_event_end(struct perf_evsel *evsel,
+ struct perf_sample *sample __maybe_unused,
+ struct event_key *key __maybe_unused)
+{
+ return (!strcmp(evsel->name, kvm_trap_exit_trace));
+}
+
+static void trap_event_decode_key(struct perf_kvm_stat *kvm __maybe_unused,
+ struct event_key *key,
+ char *decode)
+{
+ const char *trap_reason = get_trap_reason(key->key);
+
+ scnprintf(decode, decode_str_len, "%s", trap_reason);
+}
+
+static struct kvm_events_ops trap_events = {
+ .is_begin_event = trap_event_begin,
+ .is_end_event = trap_event_end,
+ .decode_key = trap_event_decode_key,
+ .name = "TRAP-EVENT",
+};
+
const char *kvm_events_tp[] = {
"kvm:kvm_entry",
"kvm:kvm_exit",
+ "kvm:kvm_trap_enter",
+ "kvm:kvm_trap_exit",
NULL,
};
struct kvm_reg_events_ops kvm_reg_events_ops[] = {
{ .name = "vmexit", .ops = &exit_events },
+ { .name = "trap", .ops = &trap_events },
{ NULL, NULL },
};
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v1 1/5] KVM: arm/arm64: Remove kvm_mmio_emulate tracepoint
2019-06-12 9:08 ` [PATCH v1 1/5] KVM: arm/arm64: Remove kvm_mmio_emulate tracepoint Zenghui Yu
@ 2019-06-12 12:48 ` James Morse
2019-06-13 11:20 ` Zenghui Yu
0 siblings, 1 reply; 12+ messages in thread
From: James Morse @ 2019-06-12 12:48 UTC (permalink / raw)
To: Zenghui Yu
Cc: acme, kvm, marc.zyngier, catalin.marinas, will.deacon,
linux-kernel, acme, linuxarm, linux-perf-users, peterz,
alexander.shishkin, mingo, xiexiangyou, ganapatrao.kulkarni,
namhyung, jolsa, kvmarm, linux-arm-kernel
Hi,
On 12/06/2019 10:08, Zenghui Yu wrote:
> In current KVM/ARM code, no one will invoke trace_kvm_mmio_emulate().
> Remove this TRACE_EVENT definition.
Oooer. We can't just go removing these things, they are visible to user-space.
I recall an article on this: https://lwn.net/Articles/737530/
"Another attempt to address the tracepoint ABI problem"
I agree this is orphaned, it was added by commit 45e96ea6b369 ("KVM: ARM: Handle I/O
aborts"), but there never was a caller.
The problem with removing it is /sys/kernel/debug/tracing/events/kvm/kvm_mmio_emulate
disappears. Any program relying on that being present (but useless) is now broken.
Thanks,
James
> diff --git a/virt/kvm/arm/trace.h b/virt/kvm/arm/trace.h
> index 204d210..8b7dff2 100644
> --- a/virt/kvm/arm/trace.h
> +++ b/virt/kvm/arm/trace.h
> @@ -114,27 +114,6 @@
> __entry->type, __entry->vcpu_idx, __entry->irq_num, __entry->level)
> );
>
> -TRACE_EVENT(kvm_mmio_emulate,
> - TP_PROTO(unsigned long vcpu_pc, unsigned long instr,
> - unsigned long cpsr),
> - TP_ARGS(vcpu_pc, instr, cpsr),
> -
> - TP_STRUCT__entry(
> - __field( unsigned long, vcpu_pc )
> - __field( unsigned long, instr )
> - __field( unsigned long, cpsr )
> - ),
> -
> - TP_fast_assign(
> - __entry->vcpu_pc = vcpu_pc;
> - __entry->instr = instr;
> - __entry->cpsr = cpsr;
> - ),
> -
> - TP_printk("Emulate MMIO at: 0x%08lx (instr: %08lx, cpsr: %08lx)",
> - __entry->vcpu_pc, __entry->instr, __entry->cpsr)
> -);
> -
> TRACE_EVENT(kvm_unmap_hva_range,
> TP_PROTO(unsigned long start, unsigned long end),
> TP_ARGS(start, end),
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 2/5] KVM: arm/arm64: Adjust entry/exit and trap related tracepoints
2019-06-12 9:08 ` [PATCH v1 2/5] KVM: arm/arm64: Adjust entry/exit and trap related tracepoints Zenghui Yu
@ 2019-06-12 12:49 ` James Morse
2019-06-13 11:28 ` Zenghui Yu
0 siblings, 1 reply; 12+ messages in thread
From: James Morse @ 2019-06-12 12:49 UTC (permalink / raw)
To: Zenghui Yu
Cc: mark.rutland, acme, kvm, marc.zyngier, catalin.marinas,
will.deacon, linux-kernel, acme, christoffer.dall,
linux-perf-users, peterz, alexander.shishkin, mingo, linuxarm,
wanghaibin.wang, ganapatrao.kulkarni, namhyung, jolsa, kvmarm,
linux-arm-kernel, xiexiangyou
Hi,
On 12/06/2019 10:08, Zenghui Yu wrote:
> Currently, we use trace_kvm_exit() to report exception type (e.g.,
> "IRQ", "TRAP") and exception class (ESR_ELx's bit[31:26]) together.
(They both caused an exit!)
> But hardware only saves the exit class to ESR_ELx on synchronous
EC is the 'Exception Class'. Exit is KVM/Linux's terminology.
> exceptions, not on asynchronous exceptions. When the guest exits
> due to external interrupts, we will get tracing output like:
>
> "kvm_exit: IRQ: HSR_EC: 0x0000 (UNKNOWN), PC: 0xffff87259e30"
>
> Obviously, "HSR_EC" here is meaningless.
I assume we do it this way so there is only one guest-exit tracepoint that catches all exits.
I don't think its a problem if user-space has to know the EC isn't set for asynchronous
exceptions, this is a property of the architecture and anything using these trace-points
is already arch specific.
> This patch splits "exit" and "trap" events by adding two tracepoints
> explicitly in handle_trap_exceptions(). Let trace_kvm_exit() report VM
> exit events, and trace_kvm_trap_exit() report VM trap events.
>
> These tracepoints are adjusted also in preparation for supporting
> 'perf kvm stat' on arm64.
Because the existing tracepoints are ABI, I don't think we can change them.
We can add new ones if there is something that a user reasonably needs to trace, and can't
be done any other way.
What can't 'perf kvm stat' do with the existing trace points?
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 516aead..af3c732 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -264,7 +264,10 @@ static int handle_trap_exceptions(struct kvm_vcpu *vcpu, struct kvm_run *run)
> exit_handle_fn exit_handler;
>
> exit_handler = kvm_get_exit_handler(vcpu);
> + trace_kvm_trap_enter(vcpu->vcpu_id,
> + kvm_vcpu_trap_get_class(vcpu));
> handled = exit_handler(vcpu, run);
> + trace_kvm_trap_exit(vcpu->vcpu_id);
> }
Why are there two? Are you using this to benchmark the exit_handler()?
As we can't remove the EC from the exit event, I don't think this tells us anything new.
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 90cedeb..9f63fd9 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -758,7 +758,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
> /**************************************************************
> * Enter the guest
> */
> - trace_kvm_entry(*vcpu_pc(vcpu));
> + trace_kvm_entry(vcpu->vcpu_id, *vcpu_pc(vcpu));
Why do you need the PC? It was exported on exit.
(its mostly junk for user-space anyway, you can't infer anything from it)
Thanks,
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 1/5] KVM: arm/arm64: Remove kvm_mmio_emulate tracepoint
2019-06-12 12:48 ` James Morse
@ 2019-06-13 11:20 ` Zenghui Yu
0 siblings, 0 replies; 12+ messages in thread
From: Zenghui Yu @ 2019-06-13 11:20 UTC (permalink / raw)
To: James Morse
Cc: acme, Wanghaibin (D),
kvm, marc.zyngier, catalin.marinas, will.deacon, linux-kernel,
acme, linuxarm, linux-perf-users, peterz, alexander.shishkin,
mingo, xiexiangyou, ganapatrao.kulkarni, namhyung, jolsa, kvmarm,
linux-arm-kernel
Hi James,
On 2019/6/12 20:48, James Morse wrote:
> Hi,
>
> On 12/06/2019 10:08, Zenghui Yu wrote:
>> In current KVM/ARM code, no one will invoke trace_kvm_mmio_emulate().
>> Remove this TRACE_EVENT definition.
>
> Oooer. We can't just go removing these things, they are visible to user-space.
>
> I recall an article on this: https://lwn.net/Articles/737530/
> "Another attempt to address the tracepoint ABI problem"
>
> I agree this is orphaned, it was added by commit 45e96ea6b369 ("KVM: ARM: Handle I/O
> aborts"), but there never was a caller.
>
> The problem with removing it is /sys/kernel/debug/tracing/events/kvm/kvm_mmio_emulate
> disappears. Any program relying on that being present (but useless) is now broken.
Thanks for the reminder.
It turned out that I knew little about the tracepoint ABI :( .
I'm OK to just drop this patch in next version.
Thanks,
zenghui
.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 2/5] KVM: arm/arm64: Adjust entry/exit and trap related tracepoints
2019-06-12 12:49 ` James Morse
@ 2019-06-13 11:28 ` Zenghui Yu
2019-06-17 11:19 ` James Morse
0 siblings, 1 reply; 12+ messages in thread
From: Zenghui Yu @ 2019-06-13 11:28 UTC (permalink / raw)
To: James Morse
Cc: mark.rutland, acme, kvm, marc.zyngier, catalin.marinas,
will.deacon, linux-kernel, acme, christoffer.dall,
linux-perf-users, peterz, alexander.shishkin, mingo, linuxarm,
wanghaibin.wang, ganapatrao.kulkarni, namhyung, jolsa, kvmarm,
linux-arm-kernel, xiexiangyou
Hi James,
On 2019/6/12 20:49, James Morse wrote:
> Hi,
>
> On 12/06/2019 10:08, Zenghui Yu wrote:
>> Currently, we use trace_kvm_exit() to report exception type (e.g.,
>> "IRQ", "TRAP") and exception class (ESR_ELx's bit[31:26]) together.
>
> (They both caused an exit!)
>
>
>> But hardware only saves the exit class to ESR_ELx on synchronous
>
> EC is the 'Exception Class'. Exit is KVM/Linux's terminology.
Yes, a stupid mistake ;-)
>> exceptions, not on asynchronous exceptions. When the guest exits
>> due to external interrupts, we will get tracing output like:
>>
>> "kvm_exit: IRQ: HSR_EC: 0x0000 (UNKNOWN), PC: 0xffff87259e30"
>>
>> Obviously, "HSR_EC" here is meaningless.
>
> I assume we do it this way so there is only one guest-exit tracepoint that catches all exits.
> I don't think its a problem if user-space has to know the EC isn't set for asynchronous
> exceptions, this is a property of the architecture and anything using these trace-points
> is already arch specific.
Actually, *no* problem in current implementation, and I'm OK to still
keep the EC in trace_kvm_exit(). What I really want to do is adding the
EC in trace_trap_enter (the new tracepoint), will explain it later.
>> This patch splits "exit" and "trap" events by adding two tracepoints
>> explicitly in handle_trap_exceptions(). Let trace_kvm_exit() report VM
>> exit events, and trace_kvm_trap_exit() report VM trap events.
>>
>> These tracepoints are adjusted also in preparation for supporting
>> 'perf kvm stat' on arm64.
>
> Because the existing tracepoints are ABI, I don't think we can change them.
>
> We can add new ones if there is something that a user reasonably needs to trace, and can't
> be done any other way.
>
> What can't 'perf kvm stat' do with the existing trace points?
(A good question! I should have made it clear in the commit message,
forgive me.)
First, how does 'perf kvm stat' interact with tracepoints?
We have three handlers for a specific event (e.g., "VM-EXIT") --
"is_begin_event", "is_end_event", "decode_key". The first two handlers
make use of two existing tracepoints ("kvm:kvm_exit" & "kvm:kvm_entry")
to check when the VM-EXIT events started/ended, thus the time difference
stats, event start/end time etc. can be calculated.
"is_begin_event" handler gets a *key* from the "ret" field (exit_code)
of "kvm:kvm_exit" payload, and "decode_key" handler makes use of the
*key* to find out the reason for the VM-EXIT event. Of course we should
maintain the mapping between exit_code and exit_reason in userspace.
These are all what *patch #4* had done, #4 is a simple patch to review!
Oh, we can also set "vcpu_id_str" to achieve per vcpu event record, but
currently, we only have the "vcpu_pc" field in "kvm:kvm_entry", without
something like "vcpu_id".
perf people must have a much deeper understanding of this.
OK, next comes the more important question - what should/can we do to
the tracepoints in preparation of 'perf kvm stat' on arm64?
From the article you've provided, it's clear that we can't remove the EC
from trace_kvm_exit(). But can we add something like "vcpu_id" into
(at least) trace_kvm_entry(), just like what this patch has done?
If not, which means we have to keep the existing tracepoints totally
unchanged, then 'perf kvm stat' will have no way to record/report per
vcpu VM-EXIT events (other arch like X86, powerpc, s390 etc. have this
capability, if I understand it correctly).
As for TRAP events, should we consider adding two new tracepoints --
"kvm_trap_enter" and "kvm_trap_exit", to keep tracking of the trap
handling process? We should also record the EC in "kvm_trap_enter",
which will be used as *key* in TRAP event's "is_begin_event" handler.
Patch #5 tells us the whole story, it's simple too.
What do you suggest?
>> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
>> index 516aead..af3c732 100644
>> --- a/arch/arm64/kvm/handle_exit.c
>> +++ b/arch/arm64/kvm/handle_exit.c
>> @@ -264,7 +264,10 @@ static int handle_trap_exceptions(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> exit_handle_fn exit_handler;
>>
>> exit_handler = kvm_get_exit_handler(vcpu);
>> + trace_kvm_trap_enter(vcpu->vcpu_id,
>> + kvm_vcpu_trap_get_class(vcpu));
>> handled = exit_handler(vcpu, run);
>> + trace_kvm_trap_exit(vcpu->vcpu_id);
>> }
>
> Why are there two? Are you using this to benchmark the exit_handler()?
Almostly yes. Let perf know when the TRAP handling event start/end,
and ...
> As we can't remove the EC from the exit event, I don't think this tells us anything new.
As explained above, this EC is for 'perf kvm stat'.
>> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
>> index 90cedeb..9f63fd9 100644
>> --- a/virt/kvm/arm/arm.c
>> +++ b/virt/kvm/arm/arm.c
>> @@ -758,7 +758,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> /**************************************************************
>> * Enter the guest
>> */
>> - trace_kvm_entry(*vcpu_pc(vcpu));
>> + trace_kvm_entry(vcpu->vcpu_id, *vcpu_pc(vcpu));
>
> Why do you need the PC? It was exported on exit.
> (its mostly junk for user-space anyway, you can't infer anything from it)
(I mainly wanted to add the "vcpu->vcpu_id" here.)
It seems that we can't just remove the PC, which will cause ABI change?
Thanks for your reviewing!
zenghui
.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 2/5] KVM: arm/arm64: Adjust entry/exit and trap related tracepoints
2019-06-13 11:28 ` Zenghui Yu
@ 2019-06-17 11:19 ` James Morse
2019-06-21 13:25 ` Zenghui Yu
0 siblings, 1 reply; 12+ messages in thread
From: James Morse @ 2019-06-17 11:19 UTC (permalink / raw)
To: Zenghui Yu
Cc: mark.rutland, acme, kvm, marc.zyngier, catalin.marinas,
will.deacon, linux-kernel, acme, christoffer.dall,
linux-perf-users, peterz, alexander.shishkin, mingo, linuxarm,
wanghaibin.wang, ganapatrao.kulkarni, namhyung, jolsa, kvmarm,
linux-arm-kernel, xiexiangyou
Hi Zenghui,
On 13/06/2019 12:28, Zenghui Yu wrote:
> On 2019/6/12 20:49, James Morse wrote:
>> On 12/06/2019 10:08, Zenghui Yu wrote:
>>> Currently, we use trace_kvm_exit() to report exception type (e.g.,
>>> "IRQ", "TRAP") and exception class (ESR_ELx's bit[31:26]) together.
>>> But hardware only saves the exit class to ESR_ELx on synchronous
>>> exceptions, not on asynchronous exceptions. When the guest exits
>>> due to external interrupts, we will get tracing output like:
>>>
>>> "kvm_exit: IRQ: HSR_EC: 0x0000 (UNKNOWN), PC: 0xffff87259e30"
>>>
>>> Obviously, "HSR_EC" here is meaningless.
>> I assume we do it this way so there is only one guest-exit tracepoint that catches all
>> exits.
>> I don't think its a problem if user-space has to know the EC isn't set for asynchronous
>> exceptions, this is a property of the architecture and anything using these trace-points
>> is already arch specific.
> Actually, *no* problem in current implementation, and I'm OK to still
> keep the EC in trace_kvm_exit(). What I really want to do is adding the
> EC in trace_trap_enter (the new tracepoint), will explain it later.
>>> This patch splits "exit" and "trap" events by adding two tracepoints
>>> explicitly in handle_trap_exceptions(). Let trace_kvm_exit() report VM
>>> exit events, and trace_kvm_trap_exit() report VM trap events.
>>>
>>> These tracepoints are adjusted also in preparation for supporting
>>> 'perf kvm stat' on arm64.
>>
>> Because the existing tracepoints are ABI, I don't think we can change them.
>>
>> We can add new ones if there is something that a user reasonably needs to trace, and can't
>> be done any other way.
>>
>> What can't 'perf kvm stat' do with the existing trace points?
> First, how does 'perf kvm stat' interact with tracepoints?
Start at the beginning, good idea. (I've never used this thing!)
> We have three handlers for a specific event (e.g., "VM-EXIT") --
> "is_begin_event", "is_end_event", "decode_key". The first two handlers
> make use of two existing tracepoints ("kvm:kvm_exit" & "kvm:kvm_entry")
> to check when the VM-EXIT events started/ended, thus the time difference
> stats, event start/end time etc. can be calculated.
> "is_begin_event" handler gets a *key* from the "ret" field (exit_code)
> of "kvm:kvm_exit" payload, and "decode_key" handler makes use of the
> *key* to find out the reason for the VM-EXIT event. Of course we should
> maintain the mapping between exit_code and exit_reason in userspace.
Interpreting 'ret' is going to get tricky if we change those values on a whim. Its
internal to the KVM arch code.
> These are all what *patch #4* had done, #4 is a simple patch to review!
> Oh, we can also set "vcpu_id_str" to achieve per vcpu event record, but
> currently, we only have the "vcpu_pc" field in "kvm:kvm_entry", without
> something like "vcpu_id".
Heh, so from the trace-point data, you can't know which on is vcpu-0 and which is vcpu-1.
> OK, next comes the more important question - what should/can we do to
> the tracepoints in preparation of 'perf kvm stat' on arm64?
>
> From the article you've provided, it's clear that we can't remove the EC
> from trace_kvm_exit(). But can we add something like "vcpu_id" into
> (at least) trace_kvm_entry(), just like what this patch has done?
Adding something is still likely to break a badly written user-space that is trying to
parse the trace information. A regex picking out the last argument will now get a
different value.
> If not, which means we have to keep the existing tracepoints totally
> unchanged, then 'perf kvm stat' will have no way to record/report per
> vcpu VM-EXIT events (other arch like X86, powerpc, s390 etc. have this
> capability, if I understand it correctly).
Well, you get the events, but you don't know which vCPU is which. You can map this back to
the pid of the host thread assuming user-space isn't moving vcpu between host threads.
If we're really stuck: Adding tracepoints to KVM-core's vcpu get/put, that export the
vcpu_id would let you map pid->vcpu_id, which you can then use for the batch of enter/exit
events that come before a final vcpu put.
grepping "vpu_id" shows perf has a mapping for which arch-specific argument in enter/exit
is the vcpu-id. Done with this core-code mapping, you could drop that code...
But I'd be a little nervous adding a new trace-point to work around an ABI problem, as we
may have just moved the ABI problem! (What does a user of a vcpu_put tracepoint really need?)
> As for TRAP events, should we consider adding two new tracepoints --
> "kvm_trap_enter" and "kvm_trap_exit", to keep tracking of the trap
> handling process? We should also record the EC in "kvm_trap_enter", which will be used as
> *key* in TRAP event's "is_begin_event" handler.
The EC can't change between trace_kvm_exit() and handle_exit(), so you already have this.
What are the 'trap' trace points needed for? You get the timing and 'exception class' from
the guest enter/exit tracepoints. What about handle_exit() can't you work out from this?
> Patch #5 tells us the whole story, it's simple too.
(I only skimmed the perf patches, I'll go back now that I know a little more about what
you're doing)
> What do you suggest?
We can explore the vcpu_load()/vcpu_put() trace idea, (it may not work for some other
reason). I'd like to understand what the 'trap' tracepoints are needed for.
Thanks,
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 2/5] KVM: arm/arm64: Adjust entry/exit and trap related tracepoints
2019-06-17 11:19 ` James Morse
@ 2019-06-21 13:25 ` Zenghui Yu
0 siblings, 0 replies; 12+ messages in thread
From: Zenghui Yu @ 2019-06-21 13:25 UTC (permalink / raw)
To: James Morse
Cc: mark.rutland, acme, kvm, marc.zyngier, catalin.marinas,
will.deacon, linux-kernel, acme, christoffer.dall,
linux-perf-users, peterz, alexander.shishkin, mingo, linuxarm,
wanghaibin.wang, ganapatrao.kulkarni, namhyung, jolsa, kvmarm,
linux-arm-kernel, xiexiangyou
Hi James,
sorry for the late reply.
On 2019/6/17 19:19, James Morse wrote:
> Hi Zenghui,
>
> On 13/06/2019 12:28, Zenghui Yu wrote:
>> On 2019/6/12 20:49, James Morse wrote:
>>> On 12/06/2019 10:08, Zenghui Yu wrote:
>>>> Currently, we use trace_kvm_exit() to report exception type (e.g.,
>>>> "IRQ", "TRAP") and exception class (ESR_ELx's bit[31:26]) together.
>>>> But hardware only saves the exit class to ESR_ELx on synchronous
>>>> exceptions, not on asynchronous exceptions. When the guest exits
>>>> due to external interrupts, we will get tracing output like:
>>>>
>>>> "kvm_exit: IRQ: HSR_EC: 0x0000 (UNKNOWN), PC: 0xffff87259e30"
>>>>
>>>> Obviously, "HSR_EC" here is meaningless.
>
>>> I assume we do it this way so there is only one guest-exit tracepoint that catches all
>>> exits.
>>> I don't think its a problem if user-space has to know the EC isn't set for asynchronous
>>> exceptions, this is a property of the architecture and anything using these trace-points
>>> is already arch specific.
>
>> Actually, *no* problem in current implementation, and I'm OK to still
>> keep the EC in trace_kvm_exit(). What I really want to do is adding the
>> EC in trace_trap_enter (the new tracepoint), will explain it later.
>
>
>>>> This patch splits "exit" and "trap" events by adding two tracepoints
>>>> explicitly in handle_trap_exceptions(). Let trace_kvm_exit() report VM
>>>> exit events, and trace_kvm_trap_exit() report VM trap events.
>>>>
>>>> These tracepoints are adjusted also in preparation for supporting
>>>> 'perf kvm stat' on arm64.
>>>
>>> Because the existing tracepoints are ABI, I don't think we can change them.
>>>
>>> We can add new ones if there is something that a user reasonably needs to trace, and can't
>>> be done any other way.
>>>
>>> What can't 'perf kvm stat' do with the existing trace points?
>
>> First, how does 'perf kvm stat' interact with tracepoints?
>
> Start at the beginning, good idea. (I've never used this thing!)
>
>
>> We have three handlers for a specific event (e.g., "VM-EXIT") --
>> "is_begin_event", "is_end_event", "decode_key". The first two handlers
>> make use of two existing tracepoints ("kvm:kvm_exit" & "kvm:kvm_entry")
>> to check when the VM-EXIT events started/ended, thus the time difference
>> stats, event start/end time etc. can be calculated.
>
>> "is_begin_event" handler gets a *key* from the "ret" field (exit_code)
>> of "kvm:kvm_exit" payload, and "decode_key" handler makes use of the
>> *key* to find out the reason for the VM-EXIT event. Of course we should
>> maintain the mapping between exit_code and exit_reason in userspace.
>
> Interpreting 'ret' is going to get tricky if we change those values on a whim. Its
> internal to the KVM arch code.
Yes. We have to keep the definition of 'ret' and the mapping
(kvm_arm_exception_type) consistent between user side and kernel side.
Specifically,
kernel side: arch/arm64/include/asm/kvm_asm.h
user side: tools/perf/arch/arm64/util/aarch64_guest_exits.h (patch #4)
Do we have a better approach?
>> These are all what *patch #4* had done, #4 is a simple patch to review!
>
>> Oh, we can also set "vcpu_id_str" to achieve per vcpu event record, but
>> currently, we only have the "vcpu_pc" field in "kvm:kvm_entry", without
>> something like "vcpu_id".
>
> Heh, so from the trace-point data, you can't know which on is vcpu-0 and which is vcpu-1.
Yes!
>> OK, next comes the more important question - what should/can we do to
>> the tracepoints in preparation of 'perf kvm stat' on arm64?
>>
>> From the article you've provided, it's clear that we can't remove the EC
>> from trace_kvm_exit(). But can we add something like "vcpu_id" into
>> (at least) trace_kvm_entry(), just like what this patch has done?
>
> Adding something is still likely to break a badly written user-space that is trying to
> parse the trace information. A regex picking out the last argument will now get a
> different value.
>
>
>> If not, which means we have to keep the existing tracepoints totally
>> unchanged, then 'perf kvm stat' will have no way to record/report per
>> vcpu VM-EXIT events (other arch like X86, powerpc, s390 etc. have this
>> capability, if I understand it correctly).
>
> Well, you get the events, but you don't know which vCPU is which. You can map this back to
> the pid of the host thread assuming user-space isn't moving vcpu between host threads.
>
> If we're really stuck: Adding tracepoints to KVM-core's vcpu get/put, that export the
> vcpu_id would let you map pid->vcpu_id, which you can then use for the batch of enter/exit
> events that come before a final vcpu put.
> grepping "vpu_id" shows perf has a mapping for which arch-specific argument in enter/exit
> is the vcpu-id. Done with this core-code mapping, you could drop that code...
Yes. In the current 'perf kvm' implementation, we make use of the
"vcpu id" field (specified by vcpu_id_str, differ between arch) of
"kvm:kvm_entry" tracepoint payload, to achieve per vcpu record/report.
(Details in per_vcpu_record() in tools/perf/builtin-kvm.c)
Adding tracepoints in vcpu_load()/vcpu_put() might be a good idea, we
can get "vcpu id" information without breaking existing tracepoint ABI.
And I think other arch will benefit from this way, for those who haven't
supported 'perf kvm stat' yet and don't have "vcpu id" info in the
"kvm:kvm_entry" tracepoint.
But there is at least one problem (as I can see)... KVM will not always
do a vcpu_load()/vcpu_put(), while guest always enters/exits.
In the worst case, if KVM can always handle guest's exits, perf will not
have a chance to catch vcpu_load()/vcpu_put(). And still, we fail to get
per vcpu statistical analysis.
I've written a simple patch to prove this, attached at the end of this
mail. I run 'perf kvm stat record/report' against a 4-VCPU guest, but
only vcpu-3 will be reported, as only vcpu-3 is doing some MMIO access
and we have to return to user space (and vcpu_load() will be invoked).
I'm not sure if I (likely) missed some important points you've provided.
> But I'd be a little nervous adding a new trace-point to work around an ABI problem, as we
> may have just moved the ABI problem! (What does a user of a vcpu_put tracepoint really need?)
>
>
>> As for TRAP events, should we consider adding two new tracepoints --
>> "kvm_trap_enter" and "kvm_trap_exit", to keep tracking of the trap
>> handling process? We should also record the EC in "kvm_trap_enter", which will be used as
>> *key* in TRAP event's "is_begin_event" handler.
>
> The EC can't change between trace_kvm_exit() and handle_exit(), so you already have this.
>
> What are the 'trap' trace points needed for? You get the timing and 'exception class' from
> the guest enter/exit tracepoints. What about handle_exit() can't you work out from this?
In short, these two trap tracepoints are for patch #5.
Some users (me) may want to know, how many traps a guest has in a given
period of time, how many times a particular type of trap (e.g., Dabort)
has occurred, and how long each trap has been processed. That's what
patch #5 does, you can get these info through 'perf kvm stat report
--event=trap'.
If we use guest enter/exit tracepoints to support TRAP events, there
will be two problems:
1) the timing becomes inaccurate (longer than the real timing)
2) the reported 'EC' becomes "Unknown" in the case when guest exits
due to IRQ, as we set 'esr_ec' to 0 on asynchronous exceptions,
in trace_kvm_exit.
>> Patch #5 tells us the whole story, it's simple too.
>
> (I only skimmed the perf patches, I'll go back now that I know a little more about what
> you're doing)
Much appreciated :)
>> What do you suggest?
>
> We can explore the vcpu_load()/vcpu_put() trace idea, (it may not work for some other
> reason). I'd like to understand what the 'trap' tracepoints are needed for.
Thanks for your suggestion!
Btw, I have collected some useful links, attached here, to share with
someone who're interested in this series.
[1] the initial idea for 'perf kvm stat':
https://events.static.linuxfound.org/images/stories/pdf/lcjp2012_guangrong.pdf
[2] a discussion on improving kvm_exit tracepoint:
https://patchwork.kernel.org/patch/7097311/
Thanks,
zenghui
---8<---
Two tracepoints have already been added in vcpu_load/put().
---
tools/perf/arch/arm64/util/kvm-stat.c | 2 ++
tools/perf/builtin-kvm.c | 7 ++++++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/perf/arch/arm64/util/kvm-stat.c
b/tools/perf/arch/arm64/util/kvm-stat.c
index 41b28de..a91fe7d 100644
--- a/tools/perf/arch/arm64/util/kvm-stat.c
+++ b/tools/perf/arch/arm64/util/kvm-stat.c
@@ -103,6 +103,8 @@ static void trap_event_decode_key(struct
perf_kvm_stat *kvm __maybe_unused,
"kvm:kvm_exit",
"kvm:kvm_trap_enter",
"kvm:kvm_trap_exit",
+ "kvm:vcpu_load",
+ "kvm:vcpu_put",
NULL,
};
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index dbb6f73..f011fcf 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -81,6 +81,11 @@ bool exit_event_begin(struct perf_evsel *evsel,
return false;
}
+static bool kvm_vcpu_load_event(struct perf_evsel *evsel)
+{
+ return !strcmp(evsel->name, "kvm:vcpu_load");
+}
+
bool kvm_entry_event(struct perf_evsel *evsel)
{
return !strcmp(evsel->name, kvm_entry_trace);
@@ -400,7 +405,7 @@ struct vcpu_event_record *per_vcpu_record(struct
thread *thread,
struct perf_sample *sample)
{
/* Only kvm_entry records vcpu id. */
- if (!thread__priv(thread) && kvm_entry_event(evsel)) {
+ if (!thread__priv(thread) && kvm_vcpu_load_event(evsel)) {
struct vcpu_event_record *vcpu_record;
vcpu_record = zalloc(sizeof(*vcpu_record));
--
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-06-21 13:28 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-12 9:08 [PATCH v1 0/5] perf kvm: Add stat support on arm64 Zenghui Yu
2019-06-12 9:08 ` [PATCH v1 1/5] KVM: arm/arm64: Remove kvm_mmio_emulate tracepoint Zenghui Yu
2019-06-12 12:48 ` James Morse
2019-06-13 11:20 ` Zenghui Yu
2019-06-12 9:08 ` [PATCH v1 2/5] KVM: arm/arm64: Adjust entry/exit and trap related tracepoints Zenghui Yu
2019-06-12 12:49 ` James Morse
2019-06-13 11:28 ` Zenghui Yu
2019-06-17 11:19 ` James Morse
2019-06-21 13:25 ` Zenghui Yu
2019-06-12 9:08 ` [PATCH v1 3/5] perf tools arm64: Add support for get_cpuid() function Zenghui Yu
2019-06-12 9:08 ` [PATCH v1 4/5] perf,kvm/arm64: Add stat support on arm64 Zenghui Yu
2019-06-12 9:08 ` [PATCH v1 5/5] perf,kvm/arm64: perf-kvm-stat to report VM TRAP Zenghui Yu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).