Description of problem: just saw on virtlab101, with kvm-83-77.el5 : [root@virtlab101 ~]# dmesg |grep kvm kvm: virtualization flags detected on this hardware: vmx tpr_shadow vnmi flexpriority loaded kvm module (kvm-83-77.el5) kvm: 9480: cpu0 unimplemented perfctr wrmsr: 0x186 data 0x130079 kvm: 9480: cpu0 unimplemented perfctr wrmsr: 0xc1 data 0xffd7698c kvm: 9480: cpu0 unimplemented perfctr wrmsr: 0x186 data 0x530079 kvm: 23682: cpu0 unimplemented perfctr wrmsr: 0x186 data 0x130079 kvm: 23682: cpu0 unimplemented perfctr wrmsr: 0xc1 data 0xffd7699c kvm: 23682: cpu0 unimplemented perfctr wrmsr: 0x186 data 0x530079 [root@virtlab101 ~]# rpm -q kvm kvm-83-77.el5 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Related or not, KVM-83-77, on a 2003/64, with SPICE, without QXL, with virtio-blk b31351, not doing anything interesting (Windows update, then downloading debug symbols from MS): kvm: 27756: cpu0 unhandled rdmsr: 0xe8 Command line used (yes, I ran KVM manually): /usr/libexec/qemu-kvm -drive file=/isos/disks-vm/Neta-lee/2K3_64_blk.raw,if=virtio,boot=on,serial=w2k3_64_blk -drive file=/isos/disks-vm/Neta-lee/2K3_64_blk_disk2.raw,if=virtio,serial=blkdisk2 -fda /isos/disks-vm/Neta-lee/viostor-31351.vfd -m 2048 -net nic,model=e1000,macaddr=00:1a:4a:16:97:a9,vlan=0 -net tap,vlan=0,script=/usr/share/vdsm/qemu-ifup -localtime -name win2003-64-blk -smp 4 -qxl 1 -spice port=5945,disable-ticketing,unsecure-channels=all -usbdevice tablet -uuid 111292f9-1234-4915-899e-137f1b3a11a3 -cdrom /isos/windows/Windows2003_r2_VLK.iso -monitor stdio -boot dc -rtc-td-hack -cpu qemu64,+sse2,model=3
Unclear to me what the desired correction is for this case. Given the performance counters here are not being emulated it seems some notification logging is useful should a guest exhibit odd behavior due to this lack of emulation. Or is the issue suppressing the diagnostic output by default?
Also seen when installing 2008/R2 on kvm-83-90.el5
*** Bug 509925 has been marked as a duplicate of this bug. ***
I am seeing similar messages on a loaner Nehalem 5560 I have from Intel and I am working with various virtio RHEL5.4 guests. I also came across a closed BZ# 483561 which appears to be the same on face value, but this was supposedly fixed with errata (I have that errata installed). This system is available to jump on and look around if that helps. [root@rector qemu]# cat /proc/cpuinfo | grep "model name" model name : Intel(R) Xeon(R) CPU X5560 @ 2.80GHz --snip-- [root@rector qemu]# dmesg | grep kvm kvm: virtualization flags detected on this hardware: vmx tpr_shadow vnmi flexpriority ept vpid loaded kvm module (kvm-83-105.el5_4.1) kvm: 31693: cpu0 unimplemented perfctr wrmsr: 0x186 data 0x530079 kvm: 22709: cpu0 unimplemented perfctr wrmsr: 0x186 data 0x130079 kvm: 22709: cpu0 unimplemented perfctr wrmsr: 0xc1 data 0xffd545c2 --snip-- (about 100 lines of that) [root@rector qemu]# uname -r 2.6.18-164.2.1.el5 [root@rector qemu]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.4 (Tikanga)
oh, and just to be clear, I was not using the kvm binary directly.
(In reply to comment #10) > How come this bug private? Does not seem to contain customer or security > confidential data or other information that would justify restricting access. > > Is the information relating to the Intel CPUs partner-confidential (if so it > might be useful to add the Intel groups to the group list). No good reason - it was discovered during SVVP tests, perhaps that why I've set it as such.
Still seeing it: [root@pink-amd-autotest ~]# dmesg |grep kvm kvm: virtualization flags detected on this hardware: svm kvm: Nested Paging enabled loaded kvm module (kvm-83-161.el5) kvm: 4282: cpu0 unimplemented perfctr wrmsr: 0xc0010000 data 0x0 kvm: 4282: cpu0 unimplemented perfctr wrmsr: 0xc0010001 data 0x0 kvm: 4282: cpu0 unimplemented perfctr wrmsr: 0xc0010002 data 0x0 kvm: 4282: cpu0 unimplemented perfctr wrmsr: 0xc0010003 data 0x0 kvm: 4282: cpu1 unimplemented perfctr wrmsr: 0xc0010000 data 0x0 kvm: 4282: cpu1 unimplemented perfctr wrmsr: 0xc0010001 data 0x0 kvm: 4282: cpu1 unimplemented perfctr wrmsr: 0xc0010002 data 0x0 kvm: 4282: cpu1 unimplemented perfctr wrmsr: 0xc0010003 data 0x0 I'm running an XP/32 and Win7/64 VMs (both with Spice. [root@pink-amd-autotest ~]# rpm -qa |grep kvm kvm-83-161.el5 kmod-kvm-83-161.el5 etherboot-zroms-kvm-5.4.4-13.el5 kvm-qemu-img-83-161.el5 kvm-debuginfo-83-161.el5 kvm-tools-83-161.el5
Per my add in https://bugzilla.redhat.com/show_bug.cgi?id=609032 this is not a bug, but expected behaviour when the OS is probing to find out whether the PMU is available or not on P6 processors. We could in theory remove the MSR write warnings, but they are not doing any harm and the information is useful to have. I suggest we close this as notabug. Jes
I'd suggest we remove the warnings. Almost all users have no idea what they mean and have no idea what they should do about it. Thus we get bugs and someone has to deal with them. Removing the needless message seems a lot easier to me than confusing users have have to deal with multiple BZs.
I posted a patch for upstream for this. If it gets accepted I agree we can backport it, however if there is resistance I think it is not worth battling over. Jes
on my host , the dmesg show followings: kvm: 17827: cpu0 unimplemented perfctr wrmsr: 0x186 data 0x130079 kvm: 17827: cpu0 unimplemented perfctr wrmsr: 0xc1 data 0xffe383d8 kvm: 17827: cpu0 unimplemented perfctr wrmsr: 0x186 data 0x530079 kvm: 17827: cpu1 unimplemented perfctr wrmsr: 0x186 data 0x130079 kvm: 17827: cpu1 unimplemented perfctr wrmsr: 0xc1 data 0xffe383d8 kvm: 17827: cpu1 unimplemented perfctr wrmsr: 0x186 data 0x530079 kvm: 17827: cpu2 unimplemented perfctr wrmsr: 0x186 data 0x130079 kvm: 17827: cpu2 unimplemented perfctr wrmsr: 0xc1 data 0xffe383d8 kvm: 17827: cpu2 unimplemented perfctr wrmsr: 0x186 data 0x530079 kvm: 17827: cpu3 unimplemented perfctr wrmsr: 0x186 data 0x130079 ISO 9660 Extensions: Microsoft Joliet Level 3 ISO 9660 Extensions: RRIP_1991A qemu-kvm[17827]: segfault at 0000000001803030 rip 00000000004a1c26 rsp 00007fff9118ac90 error 4 the guest os shutdown because of qemu-kvm segfault , Does the wrmsr warnings cause segfault?
(In reply to comment #19) > on my host , the dmesg show followings: > > kvm: 17827: cpu0 unimplemented perfctr wrmsr: 0x186 data 0x130079 > kvm: 17827: cpu0 unimplemented perfctr wrmsr: 0xc1 data 0xffe383d8 > kvm: 17827: cpu0 unimplemented perfctr wrmsr: 0x186 data 0x530079 > kvm: 17827: cpu1 unimplemented perfctr wrmsr: 0x186 data 0x130079 > kvm: 17827: cpu1 unimplemented perfctr wrmsr: 0xc1 data 0xffe383d8 > kvm: 17827: cpu1 unimplemented perfctr wrmsr: 0x186 data 0x530079 > kvm: 17827: cpu2 unimplemented perfctr wrmsr: 0x186 data 0x130079 > kvm: 17827: cpu2 unimplemented perfctr wrmsr: 0xc1 data 0xffe383d8 > kvm: 17827: cpu2 unimplemented perfctr wrmsr: 0x186 data 0x530079 > kvm: 17827: cpu3 unimplemented perfctr wrmsr: 0x186 data 0x130079 > ISO 9660 Extensions: Microsoft Joliet Level 3 > ISO 9660 Extensions: RRIP_1991A > qemu-kvm[17827]: segfault at 0000000001803030 rip 00000000004a1c26 rsp > 00007fff9118ac90 error 4 > > the guest os shutdown because of qemu-kvm segfault , > > Does the wrmsr warnings cause segfault? The wrmsr's are totally unrelated to the crash you are seeing. Please open a new bugzilla with the information and provide information about what host OS you are running, qemu-kvm version, which guest, architecture, etc. Thanks, Jes
Jes, what is the status of your upstream patch and can you provide a pointer to the same? In general I'm a little leery of just yanking the diagnostic. It provides useful debug info and is printk_ratelimit-ed. If causing end user confusion is the concern, perhaps we could disable it by default and enable it via a kernel/module parameter. Extending "ignore_msrs" seems like an obvious hook.
*** Bug 507174 has been marked as a duplicate of this bug. ***
John, Upstream didn't like my patch, so it didn't go anywhere. The writes to 0186 are pretty harmless and there was a feel it was good to get the debug output. Eventually we should look at emulating some of the bits, but it hasn't exactly been high priority. Jes
Not a serious issue and workaround as above is possible to disable the diagnostic. Although in my personal experience such minimal debug output is best left enabled.
I meet is now, and vm does not continue after this error . What can I do next ?
Linux 2.6.32-358.118.1.openstack.el6.x86_64 libvirt-daemon-1.1.1-1.el6.x86_64 qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.7.x86_64