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


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Reply via email to