Bug 846633

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

(In reply to comment #0)
> Description of problem:
> boot a guest with '-cpu qemu64,+sse4_1,+sse4_2' on rhel5.9 64bit
> host(SandyBridge host), 'sse4_1 & sse4_2' were not exported to guest
> correctly, both the rhel5.9 64bit and windows2k3 sp2 64bit guest can hit
> this issue.
> 

Hi all,

   I also tried rhel5.9 64bit guest on the rhel6.4 64bit host(kernel-2.6.32-294.el6.x86_64) with the same steps, the 'sse4_1 & sse4_2' flags can be exported to the guest correctly.

Best wish.
sluo

pls try with sse4.1|sse4.2, the instruction name in guest and host are not the samw

and also check sse4.1(bit[19]) and sse4.2(bit[20]) in rhrl5 guest with x86info, seems they are not recognized by rhel5 kernel.

(In reply to comment #3)
> pls try with sse4.1|sse4.2, the instruction name in guest and host are not
> the samw
(In reply to comment #4)
> and also check sse4.1(bit[19]) and sse4.2(bit[20]) in rhrl5 guest with
> x86info, seems they are not recognized by rhel5 kernel.


Hi all,

   If i use '-cpu qemu64,+sse4.1,+sse4.2' to boot the guest, they can be exported to the guest correctly. btw i check the qemu-kvm code, should we make a choice "sse4.1|sse4_1", "sse4.2|sse4_2" or all of them can make sense ?

static const char *ext_feature_name[] = {
    "pni|sse3" /* Intel,AMD sse3 */, "pclmulqdq|pclmuldq", "dtes64", "monitor",
    "ds_cpl", "vmx", "smx", "est",
    "tm2", "ssse3", "cid", NULL,
    "fma", "cx16", "xtpr", "pdcm",
    NULL, "pcid", "dca", "sse4.1|sse4_1",
    "sse4.2|sse4_2", "x2apic", "movbe", "popcnt",
    "tsc-deadline", "aes", "xsave", "osxsave",
    "avx", NULL, NULL, "hypervisor",
};

run '# x86info -a -f' in guest.
--------------------------------------------------------------------------
CPU #2
eax in: 0x00000000, eax = 00000004 ebx = 756e6547 ecx = 6c65746e edx = 49656e69
eax in: 0x00000001, eax = 00000663 ebx = 01020800 ecx = 80180001 edx = 178bfbfd
eax in: 0x00000002, eax = 00000001 ebx = 00000000 ecx = 00000000 edx = 002c307d
eax in: 0x00000003, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0x00000004, eax = 04000121 ebx = 01c0003f ecx = 0000003f edx = 00000001

check sse4.1(bit[19]) and sse4.2(bit[20]) has exported to guest which can be seen by 'eax in: 0x00000001, eax = 00000663 ebx = 01020800 ecx = 80180001 edx = 178bfbfd'.

Best wish.
sluo

(In reply to comment #5)
>    If i use '-cpu qemu64,+sse4.1,+sse4.2' to boot the guest, they can be
> exported to the guest correctly. btw i check the qemu-kvm code, should we
> make a choice "sse4.1|sse4_1", "sse4.2|sse4_2" or all of them can make sense
> ?

For qemu-kvm, both sse4.X and sse4_X formats are synonyms and should have exactly the same results (that's what the "|" entries on the feature_name arrays mean).

(In reply to comment #6)
> (In reply to comment #5)
> >    If i use '-cpu qemu64,+sse4.1,+sse4.2' to boot the guest, they can be
> > exported to the guest correctly. btw i check the qemu-kvm code, should we
> > make a choice "sse4.1|sse4_1", "sse4.2|sse4_2" or all of them can make sense
> > ?
> 
> For qemu-kvm, both sse4.X and sse4_X formats are synonyms and should have
> exactly the same results (that's what the "|" entries on the feature_name
> arrays mean).

when boot a rhel5.9 64bit guest with '-cpu qemu64,+sse4_1,+sse4_2' on rhel5.9 64bit host, run 'x86info -a -f' in the guest as following, from 'ecx = 80000001', we can see that the 'sse4_1 & sse4_2' flags fail to export to guest correctly.
--------------------------------------------------------------------------
CPU #2
eax in: 0x00000000, eax = 00000004 ebx = 756e6547 ecx = 6c65746e edx = 49656e69
eax in: 0x00000001, eax = 00000663 ebx = 01020800 ecx = 80000001 edx = 178bfbfd
eax in: 0x00000002, eax = 00000001 ebx = 00000000 ecx = 00000000 edx = 002c307d
eax in: 0x00000003, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0x00000004, eax = 04000121 ebx = 01c0003f ecx = 0000003f edx = 00000001

eax in: 0x80000000, eax = 8000000a ebx = 68747541 ecx = 444d4163 edx = 69746e65
eax in: 0x80000001, eax = 078bfbfd ebx = 00000000 ecx = 00000002 edx = 2191abfd
eax in: 0x80000002, eax = 554d4551 ebx = 72695620 ecx = 6c617574 edx = 55504320
eax in: 0x80000003, eax = 72657620 ebx = 6e6f6973 ecx = 392e3020 edx = 0000312e
eax in: 0x80000004, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0x80000005, eax = 01ff01ff ebx = 01ff01ff ecx = 40020140 edx = 40020140
eax in: 0x80000006, eax = 00000000 ebx = 42004200 ecx = 02008140 edx = 00000000
eax in: 0x80000007, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0x80000008, eax = 00003028 ebx = 00000000 ecx = 00000001 edx = 00000000
eax in: 0x80000009, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0x8000000a, eax = 00000001 ebx = 00000010 ecx = 00000000 edx = 00000000

Family: 6 Model: 6 Stepping: 3 Type: 0 Brand: 0
CPU Model: Celeron / Mobile Pentium II Original OEM
Feature flags:
 fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflsh mmx fxsr sse sse2 ht sse3
Extended feature flags:
 SYSCALL xd em64t

    According to the Comment #5 and above all, we can see that 'sse4_1 & sse4_2' flags fail to export to guest when boot guest with '-cpu qemu64,+sse4_1,+sse4_2', but successfully if boot guest with '-cpu qemu64,+sse4.1,+sse4.2'.

Best wish.
sluo

(In reply to comment #5)
> 
>    If i use '-cpu qemu64,+sse4.1,+sse4.2' to boot the guest, they can be
> exported to the guest correctly. btw i check the qemu-kvm code, should we
> make a choice "sse4.1|sse4_1", "sse4.2|sse4_2" or all of them can make sense
> ?
> 
> static const char *ext_feature_name[] = {
>     "pni|sse3" /* Intel,AMD sse3 */, "pclmulqdq|pclmuldq", "dtes64",
> "monitor",
>     "ds_cpl", "vmx", "smx", "est",
>     "tm2", "ssse3", "cid", NULL,
>     "fma", "cx16", "xtpr", "pdcm",
>     NULL, "pcid", "dca", "sse4.1|sse4_1",
>     "sse4.2|sse4_2", "x2apic", "movbe", "popcnt",
>     "tsc-deadline", "aes", "xsave", "osxsave",
>     "avx", NULL, NULL, "hypervisor",
> };
> 
this code is from the latest qemu upstream, I check them in our rhel5 qemu code as following:
   static const char *ext_feature_name[] = {
       "pni" /* Intel,AMD sse3 */, NULL, NULL, "monitor", "ds_cpl", "vmx", NULL /* Linux smx */, "est",
       "tm2", "ssse3", "cid", NULL, NULL, "cx16", "xtpr", NULL,
       NULL, NULL, "dca", "sse4.1", "sse4.2", NULL, NULL, "popcnt",
       NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
    };

There is only "sse4.1" & "sse4.2" in rhel5 qemu code, would developer like to update them to "sse4.1|sse4_1" & "sse4.2|sse4_2" ? 

Thanks.
sluo

(In reply to comment #8)
> There is only "sse4.1" & "sse4.2" in rhel5 qemu code, would developer like
> to update them to "sse4.1|sse4_1" & "sse4.2|sse4_2" ? 
> 

There's no need to add them, unless there's some other code that depend on them. I have just checked the RHEL-5 libvirt code, and it doesn't seem to use them.

Closing as NOTABUG, as the "see4_X" flag names are simply no supported in the RHEL-5 qemu-kvm code.