kvm: vcpu unhandled rdmsr:

poma pomidorabelisima at gmail.com
Fri Dec 19 21:56:05 UTC 2014


On 19.12.2014 18:33, Paolo Bonzini wrote:
> 
> 
> On 19/12/2014 16:44, poma wrote:
>> Mister Bonzini, what are these errors?
> 
> They are harmless.  Typically it means that the VM is trying to access
> registers for performance counters or machine check exceptions.
> 
> Instead, this:
> 
>> [  125.880384] kvm: zapping shadow pages for mmio generation wraparound
> 
> should be downgraded to KERN_DEBUG severity.
> 
>> [ 4011.896698] kvm: zapping shadow pages for mmio generation wraparound
>> [ 4046.744577] kvm [4706]: vcpu0 unhandled rdmsr: 0xc0010112
>> [ 4046.815794] kvm [4706]: vcpu0 unhandled rdmsr: 0xc001100d
>> [ 4046.949092] kvm [4706]: vcpu0 unhandled rdmsr: 0xc0010001
>> [ 4046.962165] kvm [4706]: vcpu1 unhandled rdmsr: 0xc001100d
>>
>> Both Fedora 21 x64 host & Fedora 21 x64 guest are hosed, hard reset is must.
> 
> It should not be hosed because of the rdmsr.
> 
> What processor do you have in the host?  Can you include the output of
> "ps | grep qemu"?
> 
> Paolo
> 


Eccola Mister Bonzini, 

$ ps | grep qemu ; echo $?
1
$ ps axu | grep [q]emu ; echo $?
qemu      2347  101  1.6 2951384 63144 ?       Sl   21:33   8:41 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name Fedora21 -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu Opteron_G3,+wdt,+skinit,+ibs,+osvw,+3dnowprefetch,+cr8legacy,+extapic,+cmp_legacy,+3dnow,+3dnowext,+pdpe1gb,+fxsr_opt,+mmxext,+ht,+vme -m 2024 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 ...
0

/etc/libvirt/qemu/Fedora21.xml
...
<domain type='kvm'>
  ...
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc-i440fx-2.1'>hvm</type>
    ...
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <cpu mode='host-model'>
    <model fallback='allow'/>
  </cpu>
  ...
</domain>


HOST:
/proc/cpuinfo 
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 4
model name	: AMD Phenom(tm) II X4 955 Processor
stepping	: 3
microcode	: 0x10000c8
cpu MHz		: 800.000
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save vmmcall
bugs		: tlb_mmatch apic_c1e fxsave_leak
bogomips	: 6400.37
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
...

"Phenom" doesn't exist in the /usr/share/libvirt/cpu_map.xml, therefore libvirt? chooses probably the closest to specification, 
and it is always Opteron_G3, even if cpu mode='host-passthrough'.
Is this the culprit, dunno, but both systems do have a tendency to "hose".
And this is nothing new, it is ongoing long since.


GUEST:
/proc/cpuinfo 
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 6
model name	: AMD Opteron 23xx (Gen 3 Class Opteron)
stepping	: 1
microcode	: 0x1000065
cpu MHz		: 3199.998
cache size	: 512 KB
physical id	: 0
siblings	: 1
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb lm 3dnowext 3dnow rep_good nopl extd_apicid pni cx16 x2apic popcnt hypervisor cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw vmmcall
bugs		: fxsave_leak
bogomips	: 6399.99
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management:
...




More information about the devel mailing list