summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/105/mistranslation/1318091
blob: 6581c5ec5eada3e5220fe0d304ae1ab2af102253 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
mistranslation: 0.921
other: 0.894
semantic: 0.893
instruction: 0.857
assembly: 0.857
graphic: 0.845
device: 0.844
vnc: 0.826
network: 0.806
KVM: 0.789
socket: 0.788
boot: 0.774

Perfctr MSRs not available to Guest OS on AMD Phenom II

The  AMD Phenom(tm) II X4 965 Processor (family 16, model 4, stepping 3) has the 4 architecturally supported perf counters at MSRs.  The selectors are c001000-c001003, and the counters are c001004-c001007.  I've verified that the MSRs are there and working by manually setting the MSRs with msr-tools to count cycles.

The processor does not support the extended perfctr or the perfctr_nb.  These are in cpuid leaf 8000_0001.  Qemu also sees that these cpuid flags are not set, when I try launching with  -cpu host,perfctr_core,check.  However, this flag is only for the extended perfctr MSRs, which also happen to map the original four counters at c0010200.

When I run a Guest OS, that OS is unable to use the perf counter registers from c001000-7.  rdmsr and wrmsr complete, but the results are always 0.  By contrast, a wrmsr to one of the c0010200 registers causes a general protection fault (as it should, since those aren't supported).

Kernel: 3.14.0-gentoo
Qemu: 2.0.0 (gentoo) and also with 2.0.50 (commit 06b4f00d5)
Qemu command: qemu-system-x86_64 -enable-kvm -cpu host -smp 8 -m 1024 -nographic -monitor /dev/pts/4 mnt/hdd.img
cat /proc/cpuinfo:
processor	: 3
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 4
model name	: AMD Phenom(tm) II X4 965 Processor
stepping	: 3
cpu MHz		: 800.000
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 3
cpu cores	: 4
apicid		: 3
initial apicid	: 3
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
bogomips	: 6803.79
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

thanks.

i don't understand this in detail, but since the last update of qemu i can't start my virtual win7 machine. i use gnome-boxes 3.24. qemu 2.8 works, 2.9 leads to this:
Preformatted text(gnome-boxes:4301): Boxes-WARNING **: machine.vala:611: Failed to start win7: Unable to start domain: the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor, rdtscp, svm

i ask, because i also use an phenom 2 x4 and if this is the bug i don't need to opan a new one.

Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?

Hi -

I don't have the hardware readily available anymore, so I can't test it.  Might as well close the bug.

Regarding Oliver's question, it doesn't sound like the same issue I had.  I do recall that processor and qemu not supporting rdtscp (which is fine), so that problem might be some qemu startup script requesting features that aren't available.

[Expired for QEMU because there has been no activity for 60 days.]