Hi,

I strongly suspect you see the sse3 flag because the code in the RHEL3.9 
kernel is so old that it pre-dates sse4 and simply misidentifies one of
the other flags as sse3, like popcnt.

I'll check the source if I can see, but I am pretty sure this is not a bug
in RHEL6, but a limitation in RHEL3.9.

Jes

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Please provide the exact kernel version you are running in the guest.
I don't see any reference to 'sse3' in the RHEL3U9 kernel sources that
I can find.

Thanks,
Jes

Could you also provide me with the /proc/cpuinfo of a RHEL6 guest on this machine as well?

(In reply to comment #5)
> Could you also provide me with the /proc/cpuinfo of a RHEL6 guest on this
> machine as well?    

# cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 6
model name      : QEMU Virtual CPU version 0.12.1
stepping        : 3
cpu MHz         : 2405.196
cache size      : 512 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 4
wp              : yes
flags           : fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm up pni cx16 popcnt hypervisor lahf_lm abm sse4a
bogomips        : 4810.39
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

There is a flag "up" correspond for smp=1 shown in RHEL 6.0 guest, but not in RHEL 3.9 guest.

Ok so what shows as 'sse3' in the RHEL3.9 kernel is what shows up as 'pni'
in your RHEL6 output, aka the flags are consistent.

The real question is whether that flag should be enabled in the default
qemu64 cpu type or not.

From RHEL3.9 (linux-2.4.21-61):
/* Intel-defined CPU features, CPUID level 0x00000001, ecx, word 4 */
#define X86_FEATURE_SSE3	(4*32+ 0) /* Streaming SIMD Extensions-3 */

From upstream:
/* Intel-defined CPU features, CPUID level 0x00000001 (ecx), word 4 */
#define X86_FEATURE_XMM3        (4*32+ 0) /* "pni" SSE-3 */

After further discussion with Alex, John, and others, there is also a problem
with the qemu64 type which enables some incorrect flags.

I am not sure we wish to make any change to this in RHEL6 as sse3/pni is
available on all processors that KVM runs on, even if we do not enable
sse2 per default - yes I know it is very illogical.

Jes

(In reply to comment #7)
> Ok so what shows as 'sse3' in the RHEL3.9 kernel is what shows up as 'pni'
> in your RHEL6 output, aka the flags are consistent.

Personally I don't know where the "pni" moniker came from
as both Intel and AMD use "sse3" for cpuid 0000_0000, ecx & 1
with no mention of "pni" whatsoever in their respective cpuid
specifications.

FWIW qemu will accept and emit "pni" as an alias for "sse3".

> The real question is whether that flag should be enabled in the default
> qemu64 cpu type or not.
> 
> From RHEL3.9 (linux-2.4.21-61):
> /* Intel-defined CPU features, CPUID level 0x00000001, ecx, word 4 */
> #define X86_FEATURE_SSE3 (4*32+ 0) /* Streaming SIMD Extensions-3 */
> 
> From upstream:
> /* Intel-defined CPU features, CPUID level 0x00000001 (ecx), word 4 */
> #define X86_FEATURE_XMM3        (4*32+ 0) /* "pni" SSE-3 */    

Disabling it at this point is probably more of an unknown risk
vs. leaving it as-is, even if appearing somewhat odd.

Looks like this isn't a bug but rather some confusion over the
guest kernel's naming of cpuid flags.  This BTW is a persistent
issue we've been tripping over.  In the future it would be less
confusing using x86info to read the cpuid flags directly and
not rely on guest kernel interpretation.  For example:

    # x86info -a -f
        :
    eax in: 0x00000000, eax = 0000000a ebx = 756e6547 ecx = 6c65746e edx = 49656e69
    eax in: 0x00000001, eax = 00010676 ebx = 00020800 ecx = 0008e3fd edx = bfebfbff

Where for this case, sse3 is indicated via cpuid 0x00000001,
ecx & 1.  x86info also will interpret the flag bits and do its best
mapping to known names, but it as well may not do so correctly for
recently defined flag bits.  So examining the raw flag bits is the
most accurate approach.

You can find a copy of the utility tarball here:

    http://people.redhat.com/~jcooper/cpuid/utils/x86info/x86info-1.25.tgz

And vendor specs here:

    http://people.redhat.com/~jcooper/cpuid/vendor_specs/intel/241618.pdf
    http://people.redhat.com/~jcooper/cpuid/vendor_specs/amd/25481.pdf