On Mon, Feb 03, 2014 at 10:58:28AM -0200, Eduardo Habkost wrote:
> On Sun, Feb 02, 2014 at 10:59:30PM +0200, Michael S. Tsirkin wrote:
> > I observe this with guest 3.13 and host 3.13
> > when running with -cpu host on my laptop:
> >
> > [ 0.043000] Call Trace:
> > [ 0.043000] [<ffffffff81d0e873>] init_hw_perf_events+0x33/0x5cd
> > [ 0.043000] [<ffffffff81d0e840>] ? check_bugs+0x40/0x40
> > [ 0.043000] [<ffffffff8100030a>] do_one_initcall+0x13a/0x190
> > [ 0.043000] [<ffffffff81d15133>] ?
> > native_smp_prepare_cpus+0x285/0x3ee
> > [ 0.043000] [<ffffffff81d068da>] kernel_init_freeable+0x136/0x298
> > [ 0.043000] [<ffffffff816834e0>] ? rest_init+0x80/0x80
> > [ 0.043000] [<ffffffff816834ee>] kernel_init+0xe/0x130
> > [ 0.043000] [<ffffffff8169422c>] ret_from_fork+0x7c/0xb0
> > [ 0.043000] [<ffffffff816834e0>] ? rest_init+0x80/0x80
> > [ 0.043000] Code: 0f 46 c2 41 83 e8 01 89 05 63 4c fd ff 7e 2e 44 89
> > d2 b8 03 00 00 00 b9 45 03 00 00 83 e2 1f 83 fa 02 0f 4f c2 89 05 6d 4b
> > fd ff <0f> 32 48 c1 e2 20 89 c0 48 09 c2 48 89 15 0b 4c fd ff e8 c6 d3
>
> 0: 0f 46 c2 cmovbe %edx,%eax
> 3: 41 83 e8 01 sub $0x1,%r8d
> 7: 89 05 63 4c fd ff mov %eax,-0x2b39d(%rip) #
> 0xfffffffffffd4c70
> d: 7e 2e jle 0x3d
> f: 44 89 d2 mov %r10d,%edx
> 12: b8 03 00 00 00 mov $0x3,%eax
> 17: b9 45 03 00 00 mov $0x345,%ecx
> 1c: 83 e2 1f and $0x1f,%edx
> 1f: 83 fa 02 cmp $0x2,%edx
> 22: 0f 4f c2 cmovg %edx,%eax
> 25: 89 05 6d 4b fd ff mov %eax,-0x2b493(%rip) #
> 0xfffffffffffd4b98
> 2b:* 0f 32 rdmsr <-- trapping instruction
> 2d: 48 c1 e2 20 shl $0x20,%rdx
> 31: 89 c0 mov %eax,%eax
> 33: 48 09 c2 or %rax,%rdx
> 36: 48 89 15 0b 4c fd ff mov %rdx,-0x2b3f5(%rip) #
> 0xfffffffffffd4c48
> 3d: e8 .byte 0xe8
> 3e: c6 (bad)
> 3f: d3 .byte 0xd3
>
> Linux seems to be trying to read IA32_PERF_CAPABILITIES without checking the
> PDCM flag (CPUID[1].ECX[15]).
>
> I can't see why this wasn't crashing before, though. That code seems to be
> old.
>
> * v2 and above have a perf capabilities MSR
> */
> if (version > 1) {
> u64 capabilities;
>
> rdmsrl(MSR_IA32_PERF_CAPABILITIES, capabilities);
> x86_pmu.intel_cap.capabilities = capabilities;
> }
>
> Where does the "v2 and above have a perf capabilities MSR" claim in the code
> come from?
But why doesn't it crash on baremetal?
Probably baremetal simply returns 0 or something.
Let me try ..
>
>
> > [ 0.043000] RIP [<ffffffff81d0f8c3>] intel_pmu_init+0x208/0x95a
> > [ 0.043000] RSP <ffff88003f25fe18>
> > [ 0.043012] ---[ end trace 9f1576f03a80bfa0 ]---
> > [ 0.044018] Kernel panic - not syncing: Attempted to kill init!
> > exitcode=0x0000000b
> >
> > -cpu kvm64 works fine.
> >
> > Reproduces with upstream qemu a75143eda2ddf581b51e96c000974bcdfe2cbd10,
> > as well as with qemu-kvm from Fedora 19.
> >
> > Tried recent git from Linus - it still has this problem.
> >
> > --
> > MST
>
> --
> Eduardo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
