From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: unhandled wrmsr Date: Thu, 3 Jun 2010 11:30:46 +0200 Message-ID: <4C077646.3060306@amd.com> References: <4C065257.5010809@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org" To: Dave Young Return-path: Received: from tx2ehsobe002.messaging.microsoft.com ([65.55.88.12]:57715 "EHLO TX2EHSOBE003.bigfish.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933741Ab0FCJfH (ORCPT ); Thu, 3 Jun 2010 05:35:07 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Dave Young wrote: > On Wed, Jun 2, 2010 at 8:45 PM, Andre Przywara wrote: >> Dave Young wrote: >>> Hi, >>> >>> With today's git version (qemu-kvm), I got following message in kernel >>> dmesg >>> >>> [168344.215605] kvm: 27289: cpu0 unhandled wrmsr: 0x198 data 0 >> Are you sure about that? > > Sure > > 0x198 is an Intel architectural perfmon MSR and it >> is read-only. The Linux kernel source I grep'ed obeys this and does only >> rdmsr. >> You can work around this by changing the error to a warning with: >> # modprobe kvm ignore_msrs=1 > > with this param, appear following warning: > kvm: 28520: cpu0 ignored wrmsr: 0x198 data 0 As suspected. Did the boot succeed, then? > >> I'd like to see more details about the guest Linux kernel, at least the >> version you used to see why there is a wrmsr on this address. Best is you >> provide the kernel (just the vmlinuz file) somewhere so that we can >> reproduce this. Also the qemu-kvm command line would be interesting. > > Actually I tried different guest image, recreate this problem is easy. > > one of them is slackware 13.0 kernel version 2.6.29.6, you can download from: > http://www.slackware.at/data/slackware64-13.0/kernels/huge.s/ Ah, nice to meet the other Slackware user ;-) > kvm cmdline: > qemu-system-x86_64 -net nic -net tap,ifname=tap0,script=no slack64.img I tried: $ x86_64-softmmu/qemu-system-x86_64 -kernel /boot/vmlinuz-huge-2.6.29.6 -nographic -append "console=ttyS0,115200n8" -cpu core2duo,model=26,stepping=5,vendor=GenuineIntel This booted fine. Sadly I had no access to an Intel box this morning, so I had to use vendor override, but I guess this misses some features which an original Intel box has. Can you post the /proc/cpuinfo output from the guest? It seems that some feature bits trigger the behavior in the guest. The host was an Xeon5520, right? Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 448-3567-12