RE: GPF in intel_pmu_lbr_reset() with qemu -cpu host
-Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Peter Wu Sent: Sunday, March 23, 2014 6:00 AM To: Gleb Natapov Cc: Venkatesh Srinivas; Peter Zijlstra; Ingo Molnar; Andi Kleen; Linux Kernel Developers List; H. Peter Anvin; kvm@vger.kernel.org; Paolo Bonzini Subject: Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host On Saturday 22 March 2014 14:27:59 Gleb Natapov wrote: but now I have a NULL dereference (in rapl_pmu_init). Previously, when `-cpu SandyBridge` was passed to qemu, it would show this: [0.016995] Performance Events: unsupported p6 CPU model 42 no PMU driver, software events only. The same NULL pointer deref would be visible (slightly different addresses, but the Code lines are equal). With `-host`, the NULL deref with `-cpu host` contains: [0.016445] Performance Events: 16-deep LBR, IvyBridge events, Intel PMU driver. Full dmesg below. I am confused. Do you see crash now with -cpu SandyBridge and -cpu host, or -cpu host only? The RAPL crash is seen with both SandyBridge and host, I mentioned SB because that environment should be more constant than host (which depends on the CPU you have on, well, the host). Peter Is there a solution for this issue right now? I also met this GPF crash. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Thanks, Feng -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host
Il 26/03/2014 08:23, Wu, Feng ha scritto: Is there a solution for this issue right now? I also met this GPF crash. Can you attach your .config? Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host
Il 21/03/2014 20:09, H. Peter Anvin ha scritto: Calling this a bug in the PMU code is ridiculous. If KVM tells the system it os a specific vendor-family-model-stepping but diverges in behavior then it, by definition, is broken. Yeah, this is true. On AMD there is processor support for virtualizing LBR, but Intel doesn't have it. I'm not sure if generic load/save MSR support could be used to do it. Unfortunately, LBR does not have any CPUID bit to show its presence, unlike a lot of other perf-related features. So, even though calling it a bug in perf code is an exaggeration, using rdmsr_safe makes sense. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host
On Fri, Mar 21, 2014 at 12:04:32PM -0700, Venkatesh Srinivas wrote: On Fri, Mar 21, 2014 at 10:46 AM, Peter Wu pe...@lekensteyn.nl wrote: [skip] When -cpu host is used, qemu/kvm passed the host CPUID F/M/S to the guest. intel_pmu_cpu_*() - intel_pmu_lbr_reset() uses rdmsr() / wrmsr(), rather than the safe variants; if KVM does not support the particular MSRs in question, you will see a #GP(0) there. See https://lkml.org/lkml/2014/3/13/453 for a similar bug other PMU code. When kernel is compiled with guest support all rdmsr()/wrmsr() become _safe(), so the question for Peter is if his guest kernel has guest support enabled? -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host
On Saturday 22 March 2014 10:50:45 Gleb Natapov wrote: On Fri, Mar 21, 2014 at 12:04:32PM -0700, Venkatesh Srinivas wrote: On Fri, Mar 21, 2014 at 10:46 AM, Peter Wu pe...@lekensteyn.nl wrote: [skip] When -cpu host is used, qemu/kvm passed the host CPUID F/M/S to the guest. intel_pmu_cpu_*() - intel_pmu_lbr_reset() uses rdmsr() / wrmsr(), rather than the safe variants; if KVM does not support the particular MSRs in question, you will see a #GP(0) there. See https://lkml.org/lkml/2014/3/13/453 for a similar bug other PMU code. When kernel is compiled with guest support all rdmsr()/wrmsr() become _safe(), so the question for Peter is if his guest kernel has guest support enabled? Linux guest support (CONFIG_HYPERVISOR_GUEST) was not enabled, see .config in the first mail[1]. Enabling that option does not change the situation. With CONFIG_PARAVIRT and CONFIG_KVM_GUEST enabled, the PMU GPF is gone, but now I have a NULL dereference (in rapl_pmu_init). Previously, when `-cpu SandyBridge` was passed to qemu, it would show this: [0.016995] Performance Events: unsupported p6 CPU model 42 no PMU driver, software events only. The same NULL pointer deref would be visible (slightly different addresses, but the Code lines are equal). With `-host`, the NULL deref with `-cpu host` contains: [0.016445] Performance Events: 16-deep LBR, IvyBridge events, Intel PMU driver. Full dmesg below. Stepping through the debugger (for `-cpu SandyBridge`) showed that the pmu variable is NULL (in arch/x86/kernel/cpu/perf_event_intel_rapl.c) Skipping that line (`jump +1` in gdb) allowed Linux to continue booting without crashing. I have no idea what is going on here, but hopefully this information helps. Kind regards, Peter [1]: https://lkml.kernel.org/r/4055058.qLAukpngnj@al [0.00] Linux version 3.14.0-rc7-qemu-00059-g08edb33 (pc@antartica) (gcc version 4.8.2 (Ubuntu 4.8.2-16ubuntu6) ) #27 Sat Mar 22 10:06:46 CET 2014 [0.00] Command line: console=ttyS0 loglevel=8 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x3fffdfff] usable [0.00] BIOS-e820: [mem 0x3fffe000-0x3fff] reserved [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved [0.00] BIOS-e820: [mem 0xfffc-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.4 present. [0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2011 [0.00] Hypervisor detected: KVM [0.00] e820: update [mem 0x-0x0fff] usable == reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x3fffe max_arch_pfn = 0x4 [0.00] MTRR default type: write-back [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 008000 mask FF8000 uncachable [0.00] 1 disabled [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x70406, new 0x7010600070106 [0.00] found SMP MP-table at [mem 0x000f1b10-0x000f1b1f] mapped at [880f1b10] [0.00] Base memory trampoline at [88099000] 99000 size 24576 [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x019d1000, 0x019d1fff] PGTABLE [0.00] BRK [0x019d2000, 0x019d2fff] PGTABLE [0.00] BRK [0x019d3000, 0x019d3fff] PGTABLE [0.00] init_memory_mapping: [mem 0x3fc0-0x3fdf] [0.00] [mem 0x3fc0-0x3fdf] page 2M [0.00] init_memory_mapping: [mem 0x3c00-0x3fbf] [0.00] [mem 0x3c00-0x3fbf] page 2M [0.00] init_memory_mapping: [mem 0x0010-0x3bff] [0.00] [mem 0x0010-0x001f] page 4k [0.00] [mem 0x0020-0x3bff] page 2M [0.00] init_memory_mapping: [mem 0x3fe0-0x3fffdfff] [0.00] [mem 0x3fe0-0x3fffdfff] page 4k [0.00] BRK [0x019d4000, 0x019d4fff] PGTABLE [0.00] ACPI: RSDP 000f19b0 14 (v00 BOCHS ) [0.00] ACPI: RSDT 3ad3 34 (v01 BOCHS BXPCRSDT 0001 BXPC 0001) [0.00] ACPI: FACP 3177 74 (v01 BOCHS BXPCFACP 0001 BXPC 0001) [0.00] ACPI: DSDT 3fffe040
Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host
On Sat, Mar 22, 2014 at 11:05:03AM +0100, Peter Wu wrote: On Saturday 22 March 2014 10:50:45 Gleb Natapov wrote: On Fri, Mar 21, 2014 at 12:04:32PM -0700, Venkatesh Srinivas wrote: On Fri, Mar 21, 2014 at 10:46 AM, Peter Wu pe...@lekensteyn.nl wrote: [skip] When -cpu host is used, qemu/kvm passed the host CPUID F/M/S to the guest. intel_pmu_cpu_*() - intel_pmu_lbr_reset() uses rdmsr() / wrmsr(), rather than the safe variants; if KVM does not support the particular MSRs in question, you will see a #GP(0) there. See https://lkml.org/lkml/2014/3/13/453 for a similar bug other PMU code. When kernel is compiled with guest support all rdmsr()/wrmsr() become _safe(), so the question for Peter is if his guest kernel has guest support enabled? Linux guest support (CONFIG_HYPERVISOR_GUEST) was not enabled, see .config in the first mail[1]. Enabling that option does not change the situation. With CONFIG_PARAVIRT and CONFIG_KVM_GUEST enabled, the PMU GPF is gone, Yeah, it should be PARAVIRT indeed since rdmsr()/wrmsr() is substituted by _safe() using paravirt calls. but now I have a NULL dereference (in rapl_pmu_init). Previously, when `-cpu SandyBridge` was passed to qemu, it would show this: [0.016995] Performance Events: unsupported p6 CPU model 42 no PMU driver, software events only. The same NULL pointer deref would be visible (slightly different addresses, but the Code lines are equal). With `-host`, the NULL deref with `-cpu host` contains: [0.016445] Performance Events: 16-deep LBR, IvyBridge events, Intel PMU driver. Full dmesg below. I am confused. Do you see crash now with -cpu SandyBridge and -cpu host, or -cpu host only? -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host
Using _safe has it's own issues if noone checks the errors. On March 22, 2014 5:27:59 AM PDT, Gleb Natapov g...@kernel.org wrote: On Sat, Mar 22, 2014 at 11:05:03AM +0100, Peter Wu wrote: On Saturday 22 March 2014 10:50:45 Gleb Natapov wrote: On Fri, Mar 21, 2014 at 12:04:32PM -0700, Venkatesh Srinivas wrote: On Fri, Mar 21, 2014 at 10:46 AM, Peter Wu pe...@lekensteyn.nl wrote: [skip] When -cpu host is used, qemu/kvm passed the host CPUID F/M/S to the guest. intel_pmu_cpu_*() - intel_pmu_lbr_reset() uses rdmsr() / wrmsr(), rather than the safe variants; if KVM does not support the particular MSRs in question, you will see a #GP(0) there. See https://lkml.org/lkml/2014/3/13/453 for a similar bug other PMU code. When kernel is compiled with guest support all rdmsr()/wrmsr() become _safe(), so the question for Peter is if his guest kernel has guest support enabled? Linux guest support (CONFIG_HYPERVISOR_GUEST) was not enabled, see .config in the first mail[1]. Enabling that option does not change the situation. With CONFIG_PARAVIRT and CONFIG_KVM_GUEST enabled, the PMU GPF is gone, Yeah, it should be PARAVIRT indeed since rdmsr()/wrmsr() is substituted by _safe() using paravirt calls. but now I have a NULL dereference (in rapl_pmu_init). Previously, when `-cpu SandyBridge` was passed to qemu, it would show this: [0.016995] Performance Events: unsupported p6 CPU model 42 no PMU driver, software events only. The same NULL pointer deref would be visible (slightly different addresses, but the Code lines are equal). With `-host`, the NULL deref with `-cpu host` contains: [0.016445] Performance Events: 16-deep LBR, IvyBridge events, Intel PMU driver. Full dmesg below. I am confused. Do you see crash now with -cpu SandyBridge and -cpu host, or -cpu host only? -- Gleb. -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host
On Saturday 22 March 2014 14:27:59 Gleb Natapov wrote: but now I have a NULL dereference (in rapl_pmu_init). Previously, when `-cpu SandyBridge` was passed to qemu, it would show this: [0.016995] Performance Events: unsupported p6 CPU model 42 no PMU driver, software events only. The same NULL pointer deref would be visible (slightly different addresses, but the Code lines are equal). With `-host`, the NULL deref with `-cpu host` contains: [0.016445] Performance Events: 16-deep LBR, IvyBridge events, Intel PMU driver. Full dmesg below. I am confused. Do you see crash now with -cpu SandyBridge and -cpu host, or -cpu host only? The RAPL crash is seen with both SandyBridge and host, I mentioned SB because that environment should be more constant than host (which depends on the CPU you have on, well, the host). Peter -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host
cc'ing kvm people and list. On Friday 21 March 2014 18:42:40 Peter Wu wrote: Hi, While trying to run QEMU with `-enable-kvm -host cpu`, I get a GPF in intel_pmu_lbr_reset(): [0.024000] general protection fault: [#1] [0.024000] CPU: 0 PID: 1 Comm: swapper Not tainted 3.14.0-rc7-qemu-00059-g08edb33 #14 [0.024000] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [0.024000] task: 88003e05 ti: 88003e054000 task.ti: 88003e054000 [0.024000] RIP: 0010:[8101148a] [8101148a] intel_pmu_lbr_reset+0x2a/0x80 [0.024000] RSP: :88003e055e78 EFLAGS: 0002 [0.024000] RAX: RBX: 0286 RCX: 0680 [0.024000] RDX: RSI: RDI: [0.024000] RBP: 81622120 R08: 88003ffee0e0 R09: 88003e00bf00 [0.024000] R10: R11: 0004 R12: [0.024000] R13: R14: R15: [0.024000] FS: () GS:8161e000() knlGS: [0.024000] CS: 0010 DS: ES: CR0: 80050033 [0.024000] CR2: 8800019bb000 CR3: 01611000 CR4: 001407b0 [0.024000] Stack: [0.024000] 8101308a 8100e3da 8165ba62 [0.024000] 8165b5bd [0.024000] 81655dcd [0.024000] Call Trace: [0.024000] [8101308a] ? intel_pmu_cpu_starting+0xa/0x80 [0.024000] [8100e3da] ? x86_pmu_notifier+0x5a/0xc0 [0.024000] [8165ba62] ? init_hw_perf_events+0x4a5/0x4dd [0.024000] [8165b5bd] ? check_bugs+0x42/0x42 [0.024000] [81655dcd] ? do_one_initcall+0x76/0xf9 [0.024000] [81276b70] ? rest_init+0x70/0x70 [0.024000] [81655ea7] ? kernel_init_freeable+0x57/0x177 [0.024000] [81276b70] ? rest_init+0x70/0x70 [0.024000] [81276b75] ? kernel_init+0x5/0xe0 [0.024000] [8128067a] ? ret_from_fork+0x7a/0xb0 [0.024000] [81276b70] ? rest_init+0x70/0x70 [0.024000] Code: 00 8b 15 02 c4 63 00 85 d2 74 69 f6 05 af c3 63 00 3f 75 2d 85 d2 7e 5c 31 f6 31 c0 0f 1f 44 00 00 8b 0d d2 c3 63 00 89 c2 01 f1 0f 30 83 c6 01 3b 35 d3 c3 63 00 7c e9 f3 c3 0f 1f 80 00 00 00 [0.024000] RIP [8101148a] intel_pmu_lbr_reset+0x2a/0x80 [0.024000] RSP 88003e055e78 [0.024000] ---[ end trace ecbd794f78441b2c ]--- [0.024002] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b It possibly has something to do with the msr write. Reproducable with: qemu-system-x86_64 -enable-kvm -cpu host -kernel bzImage -m 1G -serial file:ser.txt In the host dmesg, the following is visible when qemu: kvm [4939]: vcpu0 unhandled wrmsr: 0x680 data 0 The full guest dmesg is shown below. The issue occurs also with v3.13.6, v3.12.14, v3.10.33 (other versions are not tested). QEMU: 1.7.0 Host kernel: v3.14-rc5 Guest kernel: v3.14-rc7-59-g08edb33 (.config on the bottom) Kind regards, Peter ### dmesg [0.00] Linux version 3.14.0-rc7-qemu-00059-g08edb33 (pc@antartica) (gcc version 4.8.2 (Ubuntu 4.8.2-16ubuntu6) ) #14 Fri Mar 21 17:30:49 CET 2014 [0.00] Command line: console=ttyS0 loglevel=8 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x3fffdfff] usable [0.00] BIOS-e820: [mem 0x3fffe000-0x3fff] reserved [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved [0.00] BIOS-e820: [mem 0xfffc-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.4 present. [0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2011 [0.00] e820: update [mem 0x-0x0fff] usable == reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x3fffe max_arch_pfn = 0x4 [0.00] MTRR default type: write-back [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 008000 mask FF8000 uncachable [0.00] 1 disabled [0.00] 2 disabled [0.00] 3 disabled [
Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host
On Fri, Mar 21, 2014 at 10:46 AM, Peter Wu pe...@lekensteyn.nl wrote: cc'ing kvm people and list. On Friday 21 March 2014 18:42:40 Peter Wu wrote: Hi, While trying to run QEMU with `-enable-kvm -host cpu`, I get a GPF in intel_pmu_lbr_reset(): [0.024000] general protection fault: [#1] [0.024000] CPU: 0 PID: 1 Comm: swapper Not tainted 3.14.0-rc7-qemu-00059-g08edb33 #14 [0.024000] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [0.024000] task: 88003e05 ti: 88003e054000 task.ti: 88003e054000 [0.024000] RIP: 0010:[8101148a] [8101148a] intel_pmu_lbr_reset+0x2a/0x80 [0.024000] RSP: :88003e055e78 EFLAGS: 0002 [0.024000] RAX: RBX: 0286 RCX: 0680 [0.024000] RDX: RSI: RDI: [0.024000] RBP: 81622120 R08: 88003ffee0e0 R09: 88003e00bf00 [0.024000] R10: R11: 0004 R12: [0.024000] R13: R14: R15: [0.024000] FS: () GS:8161e000() knlGS: [0.024000] CS: 0010 DS: ES: CR0: 80050033 [0.024000] CR2: 8800019bb000 CR3: 01611000 CR4: 001407b0 [0.024000] Stack: [0.024000] 8101308a 8100e3da 8165ba62 [0.024000] 8165b5bd [0.024000] 81655dcd [0.024000] Call Trace: [0.024000] [8101308a] ? intel_pmu_cpu_starting+0xa/0x80 [0.024000] [8100e3da] ? x86_pmu_notifier+0x5a/0xc0 [0.024000] [8165ba62] ? init_hw_perf_events+0x4a5/0x4dd [0.024000] [8165b5bd] ? check_bugs+0x42/0x42 [0.024000] [81655dcd] ? do_one_initcall+0x76/0xf9 [0.024000] [81276b70] ? rest_init+0x70/0x70 [0.024000] [81655ea7] ? kernel_init_freeable+0x57/0x177 [0.024000] [81276b70] ? rest_init+0x70/0x70 [0.024000] [81276b75] ? kernel_init+0x5/0xe0 [0.024000] [8128067a] ? ret_from_fork+0x7a/0xb0 [0.024000] [81276b70] ? rest_init+0x70/0x70 [0.024000] Code: 00 8b 15 02 c4 63 00 85 d2 74 69 f6 05 af c3 63 00 3f 75 2d 85 d2 7e 5c 31 f6 31 c0 0f 1f 44 00 00 8b 0d d2 c3 63 00 89 c2 01 f1 0f 30 83 c6 01 3b 35 d3 c3 63 00 7c e9 f3 c3 0f 1f 80 00 00 00 [0.024000] RIP [8101148a] intel_pmu_lbr_reset+0x2a/0x80 [0.024000] RSP 88003e055e78 [0.024000] ---[ end trace ecbd794f78441b2c ]--- [0.024002] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b It possibly has something to do with the msr write. Reproducable with: qemu-system-x86_64 -enable-kvm -cpu host -kernel bzImage -m 1G -serial file:ser.txt In the host dmesg, the following is visible when qemu: kvm [4939]: vcpu0 unhandled wrmsr: 0x680 data 0 The full guest dmesg is shown below. The issue occurs also with v3.13.6, v3.12.14, v3.10.33 (other versions are not tested). QEMU: 1.7.0 Host kernel: v3.14-rc5 Guest kernel: v3.14-rc7-59-g08edb33 (.config on the bottom) Kind regards, Peter ### dmesg [0.00] Linux version 3.14.0-rc7-qemu-00059-g08edb33 (pc@antartica) (gcc version 4.8.2 (Ubuntu 4.8.2-16ubuntu6) ) #14 Fri Mar 21 17:30:49 CET 2014 [0.00] Command line: console=ttyS0 loglevel=8 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x3fffdfff] usable [0.00] BIOS-e820: [mem 0x3fffe000-0x3fff] reserved [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved [0.00] BIOS-e820: [mem 0xfffc-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.4 present. [0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2011 [0.00] e820: update [mem 0x-0x0fff] usable == reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x3fffe max_arch_pfn = 0x4 [0.00] MTRR default type: write-back [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 008000 mask FF8000 uncachable [0.00] 1
Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host
Calling this a bug in the PMU code is ridiculous. If KVM tells the system it os a specific vendor-family-model-stepping but diverges in behavior then it, by definition, is broken. On March 21, 2014 12:04:32 PM PDT, Venkatesh Srinivas venkate...@google.com wrote: On Fri, Mar 21, 2014 at 10:46 AM, Peter Wu pe...@lekensteyn.nl wrote: cc'ing kvm people and list. On Friday 21 March 2014 18:42:40 Peter Wu wrote: Hi, While trying to run QEMU with `-enable-kvm -host cpu`, I get a GPF in intel_pmu_lbr_reset(): [0.024000] general protection fault: [#1] [0.024000] CPU: 0 PID: 1 Comm: swapper Not tainted 3.14.0-rc7-qemu-00059-g08edb33 #14 [0.024000] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [0.024000] task: 88003e05 ti: 88003e054000 task.ti: 88003e054000 [0.024000] RIP: 0010:[8101148a] [8101148a] intel_pmu_lbr_reset+0x2a/0x80 [0.024000] RSP: :88003e055e78 EFLAGS: 0002 [0.024000] RAX: RBX: 0286 RCX: 0680 [0.024000] RDX: RSI: RDI: [0.024000] RBP: 81622120 R08: 88003ffee0e0 R09: 88003e00bf00 [0.024000] R10: R11: 0004 R12: [0.024000] R13: R14: R15: [0.024000] FS: () GS:8161e000() knlGS: [0.024000] CS: 0010 DS: ES: CR0: 80050033 [0.024000] CR2: 8800019bb000 CR3: 01611000 CR4: 001407b0 [0.024000] Stack: [0.024000] 8101308a 8100e3da 8165ba62 [0.024000] 8165b5bd [0.024000] 81655dcd [0.024000] Call Trace: [0.024000] [8101308a] ? intel_pmu_cpu_starting+0xa/0x80 [0.024000] [8100e3da] ? x86_pmu_notifier+0x5a/0xc0 [0.024000] [8165ba62] ? init_hw_perf_events+0x4a5/0x4dd [0.024000] [8165b5bd] ? check_bugs+0x42/0x42 [0.024000] [81655dcd] ? do_one_initcall+0x76/0xf9 [0.024000] [81276b70] ? rest_init+0x70/0x70 [0.024000] [81655ea7] ? kernel_init_freeable+0x57/0x177 [0.024000] [81276b70] ? rest_init+0x70/0x70 [0.024000] [81276b75] ? kernel_init+0x5/0xe0 [0.024000] [8128067a] ? ret_from_fork+0x7a/0xb0 [0.024000] [81276b70] ? rest_init+0x70/0x70 [0.024000] Code: 00 8b 15 02 c4 63 00 85 d2 74 69 f6 05 af c3 63 00 3f 75 2d 85 d2 7e 5c 31 f6 31 c0 0f 1f 44 00 00 8b 0d d2 c3 63 00 89 c2 01 f1 0f 30 83 c6 01 3b 35 d3 c3 63 00 7c e9 f3 c3 0f 1f 80 00 00 00 [0.024000] RIP [8101148a] intel_pmu_lbr_reset+0x2a/0x80 [0.024000] RSP 88003e055e78 [0.024000] ---[ end trace ecbd794f78441b2c ]--- [0.024002] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b It possibly has something to do with the msr write. Reproducable with: qemu-system-x86_64 -enable-kvm -cpu host -kernel bzImage -m 1G -serial file:ser.txt In the host dmesg, the following is visible when qemu: kvm [4939]: vcpu0 unhandled wrmsr: 0x680 data 0 The full guest dmesg is shown below. The issue occurs also with v3.13.6, v3.12.14, v3.10.33 (other versions are not tested). QEMU: 1.7.0 Host kernel: v3.14-rc5 Guest kernel: v3.14-rc7-59-g08edb33 (.config on the bottom) Kind regards, Peter ### dmesg [0.00] Linux version 3.14.0-rc7-qemu-00059-g08edb33 (pc@antartica) (gcc version 4.8.2 (Ubuntu 4.8.2-16ubuntu6) ) #14 Fri Mar 21 17:30:49 CET 2014 [0.00] Command line: console=ttyS0 loglevel=8 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x3fffdfff] usable [0.00] BIOS-e820: [mem 0x3fffe000-0x3fff] reserved [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved [0.00] BIOS-e820: [mem 0xfffc-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.4 present. [0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2011 [0.00] e820: update [mem 0x-0x0fff] usable == reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x3fffe max_arch_pfn = 0x4 [0.00] MTRR default type: write-back [0.00] MTRR fixed ranges enabled: [0.00] 0-9
