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:
...