Bug 632257

(In reply to comment #0)

> several features are mentioned both in feature_edx and extfeature_edx.

This was a result of cloning the preexisting static cpu definitions
derived from qemu64.  Honestly it struck me odd as well as these
replicated fields aren't formally defined.  Lacking concrete justification
to remove them, I left them be.

Is this causing an issue ATM or did this just arise as being suspect in
an audit of the definitions?

No issue that I'm aware of. After discovering that duplicate features mentioned in libvirt's cpu_map.xml were caused by generating the XML from qemu's CPU definitions, we were wondering why they were duplicated in the first place and that it might be worth fixing unless there is a (probably weird) reason for not fixing it.

Ref comment #4 above, this is as intended due to being a clone
of qemu64.  Also as the cpu64-rhel[56] models are interim
bandaids this issue will obsolete along with them.

John, as I said in the bug report it affects all models in the cpu config file not just cpu64-rhel6 model (that was just an example of how it looks like). Is comment #6 still valid then?

The source of this replication is AMD for cpuid 8000_0001/edx:

 bit description
------------------------------------------------------------------------------
  23 MMX: MMXTM instructions. Same as CPUID Fn0000_0001_EDX[MMX].
  17 PSE36: page-size extensions. Same as CPUID Fn0000_0001_EDX[PSE36].
  16 PAT: page attribute table. Same as CPUID Fn0000_0001_EDX[PAT].
  15 CMOV: conditional move instructions. Same as CPUID Fn0000_0001_EDX[CMOV].
  14 MCA: machine check architecture. Same as CPUID Fn0000_0001_EDX[MCA].
  13 PGE: page global extension. Same as CPUID Fn0000_0001_EDX[PGE].
  12 MTRR: memory-type range registers. Same as CPUID Fn0000_0001_EDX[MTRR].
  09 APIC: advanced programmable interrupt controller. Same as CPUID
     Fn0000_0001_EDX[APIC].
  08 CMPXCHG8B: CMPXCHG8B instruction. Same as CPUID Fn0000_0001_EDX[CMPXCHG8B].
  07 MCE: machine check exception. Same as CPUID Fn0000_0001_EDX[MCE].
  06 PAE: physical-address extensions. Same as CPUID Fn0000_0001_EDX[PAE].
  05 MSR: AMD model-specific registers. Same as CPUID Fn0000_0001_EDX[MSR].
  04 TSC: time stamp counter. Same as CPUID Fn0000_0001_EDX[TSC].
  03 PSE: page-size extensions. Same as CPUID Fn0000_0001_EDX[PSE].
  02 DE: debugging extensions. Same as CPUID Fn0000_0001_EDX[DE].
  01 VME: virtual-mode enhancements. Same as CPUID Fn0000_0001_EDX[VME].
  00 FPU: x87 floating-point unit on-chip. Same as CPUID Fn0000_0001_EDX[FPU].

Qemu originally created a union of (AMD | Intel) cpuid definitions to
produce a vendor neutral (+/-) qemu64 definition.  This should work
in theory as where differences exist, they are disjoint.  But that
doesn't prevent code from unintentionally interpreting fields from the
wrong vendor definition.  Empirically given qemu64 this hasn't been an
issue, nor does this union exist in actual silicon.  So in general
removing the AMD defined fields from the Intel defs (and conversely)
would be more pristine.  The replication specifically called out
here isn't an issue by itself (for AMD models).  While in theory a
cleanup shouldn't introduce any breakage, it is probably best to do so
for 6.1 such that the modification will receive maximum possible soak.

[Moving BZ 630650 content here since this is related, more general,
and requires the same testing treatment.]

Description of problem:

    Case entered as a placeholder.  Currently proposed upstream changes in
    cpuid data for AMD cpus may need to be represented in both upstream
    and rhel6 cpu model config definitions pending outcome.  Ref:

    http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-09/msg02234.html

*** Bug 630650 has been marked as a duplicate of this bug. ***

Hi John,

What is the standard to define extfeature_edx of qemu64, 
'pse36', 'mca', 'mtrr' are missed if compare it with Opteron_G1 extfeature_edx

"mca" is missed if all  qemu64 extfeature_edx should be included in INTEL features

The standards for the actual definitions are the corresponding vendor
CPUID documents.  You can find both Intel and AMD documents here
(under the Reference section):

    http://cleo.tlv.redhat.com/qumrawiki/KVM/CPUModels

AMD replicates several of the common feature_edx bits in extfeature_edx,
where Intel calls these out as undefined.  In practice they weren't
causing any known problems but the model definition didn't strictly conform
to Intel's definition and it is conceivable they may confuse a guest of
processor type.

Result: Can boot guests successfully, but cpu model is incorrect in win2k8 32
create bug 682189 to trace it.

1. qemu-kvm:
qemu-kvm-0.12.1.2-2.148.el6.x86_64

2. Guest tested:
win7-32/64, win2003-32/64, win2008R2_64, Win2008-32/64, Winxp
Fedora.12-32/64, rhel6-32/64

3. cmd
qemu-kvm -monitor stdio -device isa-serial,chardev=serial_PGdp \
-drive
file='/home/images/win2008-32-virtio.qcow2',index=0,if=none,id=drive-virtio-disk1,media=disk,cache=none,format=qcow2,aio=native
-device
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk1,id=virtio-disk1
-device
virtio-net-pci,netdev=idWJZ5bH,mac=9a:dd:68:86:03:a4,id=ndev00idWJZ5bH,bus=pci.0,addr=0x3
-netdev
tap,id=idWJZ5bH,vhost=on,script='/home/scripts/qemu-ifup-switch',downscript='no'
-m 2048  -smp 2,cores=1,threads=1,sockets=2 -drive
file='/home/autotest/client/tests/kvm/isos/windows/winutils.iso',index=1,if=none,id=drive-ide0-0-0,media=cdrom,readonly=on,format=raw
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -vnc :0
-rtc base=localtime,clock=host,driftfix=none  -boot c   -usbdevice tablet

4. cpu model:
Test on Intel:
Conroe, Penryn, Nehalem ,cpu64-rhel6

Test on AMD:
Opteron_G1, Opteron_G2, Opteron_G3 ,cpu64-rhel6

5. host:
Intel:

processor	: 7
vendor_id	: GenuineIntel
cpu family	: 6
model		: 26
model name	: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz
stepping	: 4
cpu MHz		: 1600.000
cache size	: 8192 KB
physical id	: 0
siblings	: 8
core id		: 3
cpu cores	: 4
apicid		: 7
initial apicid	: 7
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid

AMD:

processor	: 11
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 8
model name	: Six-Core AMD Opteron(tm) Processor 2427
stepping	: 0
cpu MHz		: 800.000
cache size	: 512 KB
physical id	: 1
siblings	: 6
core id		: 5
cpu cores	: 6
apicid		: 13
initial apicid	: 13
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic 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 nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save

Add CCFR.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause
    New CPU models still carried over qemu64's notion of gluing
AMD defined (yet Intel undefined) feature flags in the corresponding
Intel model definitions.

Consequence
    Potential confusion of a guest and documented confusion of users
and developers.  qemu64 has been getting by with this speculative
hybrid encoding scheme but we should as accurate as possible for
specific CPU archirecture definitions.

Fix
    Remove the AMD defined flags for Intel models.

Result
    Reduced potential for guest bugs and user confusion.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0534.html

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0534.html