RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 682189 - win2k8 32bit shows incorrect cpu model when on amd host
Summary: win2k8 32bit shows incorrect cpu model when on amd host
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.1
Hardware: i386
OS: Windows
medium
medium
Target Milestone: rc
: ---
Assignee: john cooper
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 580954
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-04 11:50 UTC by Xiaoqing Wei
Modified: 2016-01-11 00:39 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-10 17:32:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
snapshots (1.76 MB, application/x-gzip)
2011-03-04 11:54 UTC, Xiaoqing Wei
no flags Details
boot the guest with G2,and it shows G3(the previous cpu use to boot the guest) (6.68 KB, text/plain)
2011-03-08 09:31 UTC, Xiaoqing Wei
no flags Details
boot the guest with G2,and it shows G3(the previous cpu use to boot the guest) (273.62 KB, image/png)
2011-03-08 09:33 UTC, Xiaoqing Wei
no flags Details
"computer's properties " displaying correct model while 'device manager' showing incorrect model (45.54 KB, image/jpeg)
2011-03-11 08:00 UTC, Xiaoqing Wei
no flags Details

Description Xiaoqing Wei 2011-03-04 11:50:50 UTC
Description of problem:
2k8_32 shows "AMD Opteron 22xx" when booting it with  qemu-kvm ..."-cpu Opteron_G1"


Version-Release number of selected component (if applicable):
qemu-kvm-0.12.1.2-2.148.el6.x86_64
kernel-2.6.32-118.el6.x86_64

How reproducible:100%
Steps to Reproduce:

Step 1. run the 2k8_32 guest using following cmd:

/home/autotest/client/tests/kvm/qemu -name 'vm1' -monitor stdio v socket,id=serial_PGdp,path=/tmp/serial-20110304-165637-5uEX,server,nowait -device isa-serial,chardev=serial_PGdp -drive file='/home/autotest/client/tests/kvm/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,netdev=idWJZ5bH,id=ndev00idWJZ5bH,bus=pci.0,addr=0x3 -netdev tap,id=idWJZ5bH,vhost=on,ifname='t0-165637-5uEX',script='/home/autotest/client/tests/kvm/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 -enable-kvm  \
\
-cpu Opteron_G1

Step 2.after guest fully startup,login the guest and open 'device management 'inside the guest .
then will see the "AMD Opteron 22xx" on processors.

if using  "-cpu Opteron_G3" sometimes it will show 22xx,sometimes will show 23xx.






Actual results:

cpu model shown by guest is differ from cmd designated.

Expected results:

cpu model shown by guest is same with cmd designated.
Additional info:


only happen on amd host,using intel host everything works well

Comment 1 Xiaoqing Wei 2011-03-04 11:54:52 UTC
Created attachment 482277 [details]
snapshots

Comment 3 Xiaoqing Wei 2011-03-04 12:29:16 UTC
The  steps to reproduce this bug is to use a cpu model to boot the guest  several times with different model 

then the incorrect cpu model shows.


eg: boot the guest with G3 for the first time,

shut it down.
than boot it with G2/G1.




additional info : host cpu model

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 4
model name      : Quad-Core AMD Opteron(tm) Processor 2376
stepping        : 2
cpu MHz         : 2294.424
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 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
bogomips        : 4588.84
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

Comment 4 john cooper 2011-03-04 14:11:11 UTC
Sounds to me as if windows may possibly be caching the cpuid
information from boot to boot -- somehow.  Could you try to
access the raw cpuid data via "x86info -a -f".  There is a
windows package available here:

    http://gnuwin32.sourceforge.net/packages/x86info.htm

This will be more definitive of what cpuid data is actually
being exposed by qemu to the guest.

Comment 5 Xiaoqing Wei 2011-03-08 09:29:32 UTC
(In reply to comment #4)
> Sounds to me as if windows may possibly be caching the cpuid
> information from boot to boot -- somehow.  Could you try to
> access the raw cpuid data via "x86info -a -f".  There is a
> windows package available here:
> 
>     http://gnuwin32.sourceforge.net/packages/x86info.htm
> 
> This will be more definitive of what cpuid data is actually
> being exposed by qemu to the guest.



Hi John

x86info shows it's a 22xx(correct model) cpu when the guest_os device_manager show 23xx (incorrect model,use to boot the guest last time.)

the attachment is generated by "x86info.exe -a -f > G2_23xx.txt"


and I also tried to use cpu-z,and it shows the correct cpu model as well.


Best Regards,
Xiaoqing

Comment 6 Xiaoqing Wei 2011-03-08 09:31:04 UTC
Created attachment 482858 [details]
boot the guest with G2,and it shows G3(the previous cpu use to boot the guest)

Comment 7 Xiaoqing Wei 2011-03-08 09:33:27 UTC
Created attachment 482859 [details]
boot the guest with G2,and it shows G3(the previous cpu use to boot the guest)

Comment 8 john cooper 2011-03-09 03:41:27 UTC
Not sure I follow you correctly.. is x86info *always*
displaying the correct qemu chosen model but the windows
guest (device manager) utility is displaying stale data
from a previous boot/model?

If so we may be violating an assumption in windows of switching
CPU models from boot to boot (I seem to recall reactivation as
an issue associated with such usage).  This just may be a windows
limitation.  Even still I have no idea why any of this behavior
appears to be AMD specific.

Comment 9 Xiaoqing Wei 2011-03-11 07:58:05 UTC
(In reply to comment #8)
> Not sure I follow you correctly.. is x86info *always*
> displaying the correct qemu chosen model 

yes, x86info /cpu-z  utility always display the correct model qemu chosen.

but the windows
> guest (device manager) utility is displaying stale data
> from a previous boot/model?
Not always win-guest display incorrect model,sometimes win2008_32 can display correct cpu model,

one thing strange. in guest, "computer-> Properties "will show the correct cpu model while "device manager" displaying incorrect model.

pls see the new attachment.

> 
> If so we may be violating an assumption in windows of switching
> CPU models from boot to boot (I seem to recall reactivation as
> an issue associated with such usage).  This just may be a windows
> limitation.  Even still I have no idea why any of this behavior
> appears to be AMD specific.

Comment 10 Xiaoqing Wei 2011-03-11 08:00:21 UTC
Created attachment 483659 [details]
"computer's properties " displaying correct model while  'device manager' showing incorrect model

Comment 11 Dor Laor 2011-03-17 13:23:48 UTC
Seems like to a real qemu/kvm bug to me. It might be an issue an windows or not.
Can we close it?

Comment 12 Suqin Huang 2011-03-18 05:21:17 UTC
(In reply to comment #11)
> Seems like to a real qemu/kvm bug to me. It might be an issue an windows or
> not.

Hi dor, did you miss some word? is it a qemu/kvm bug or not ?

> Can we close it?

Comment 13 Suqin Huang 2011-03-18 12:00:08 UTC
I boot with Opteron_G1/Opteron_G2/Opteron_G3 cpu model, device manager always show "AMD Opteron 22xx", x86info show the correct cpu model.

I will try to install win2008-32 in Opteron_G2 host, I think if the host still show incorrect cpu model, it should be windows issue. if host show correct cpu model, it should be qemu/kvm bug

Comment 14 john cooper 2011-03-18 13:12:57 UTC
(In reply to comment #13)
> I boot with Opteron_G1/Opteron_G2/Opteron_G3 cpu model, device manager always
> show "AMD Opteron 22xx", x86info show the correct cpu model.

x86info retrieves the CPUID data by executing an x86 "cpuid" instruction.
So it is the most accurate measure of what qemu is exporting to the
guest.  The fact win2008-32 is telling you something different compared
to x86info sounds suspiciously like a stale/cached cpuid data issue in
windows.

> I will try to install win2008-32 in Opteron_G2 host, I think if the host still
> show incorrect cpu model, it should be windows issue. if host show correct cpu
> model, it should be qemu/kvm bug

Have you compared the behavior of the above windows guest to windows
running on bare metal, when the same windows image is booted on
different Opteron physical processors?  If the bare metal case shows
the same suspect stale/cached cpuid data this may just be the normal
behavior when the underlying cpu model changes underfoot.  Without
knowing this I can't see a qemu/kvm problem to fix.

Comment 15 Xiaoqing Wei 2011-03-23 07:43:03 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > I boot with Opteron_G1/Opteron_G2/Opteron_G3 cpu model, device manager always
> > show "AMD Opteron 22xx", x86info show the correct cpu model.
> 
> x86info retrieves the CPUID data by executing an x86 "cpuid" instruction.
> So it is the most accurate measure of what qemu is exporting to the
> guest.  The fact win2008-32 is telling you something different compared
> to x86info sounds suspiciously like a stale/cached cpuid data issue in
> windows.
> 
> > I will try to install win2008-32 in Opteron_G2 host, I think if the host still
> > show incorrect cpu model, it should be windows issue. if host show correct cpu
> > model, it should be qemu/kvm bug
> 
> Have you compared the behavior of the above windows guest to windows
> running on bare metal, when the same windows image is booted on
> different Opteron physical processors?  If the bare metal case shows
> the same suspect stale/cached cpuid data this may just be the normal
> behavior when the underlying cpu model changes underfoot.  Without
> knowing this I can't see a qemu/kvm problem to fix.



Hi John,

do you mean for test this bug on bare metal is :
"""
1,install a win2k8 on G1 host, shut it down
2,switch G1 cpu to G3 and boot to see what model win2k8 shows and switch back,and do this several times.
"""
???


for the above testing,needs to contact the sys_admin colleagues to assist,because the server room which hosting the G1/G3 machines are no under QE's management.

and QE have communicate with the sys_admin guys,they said switch cpu on servers are no really a good solution,because switch CPU on physical host may damage CPU.and Opterons are no cheap.

can  you give a  suggestion ?

Comment 16 Xiaoqing Wei 2011-03-29 05:38:45 UTC
John,
The following Guest OS have tested and can show correct cpu model while switch cpu from boot to boot.
Guest_OS_platform       guest_cpu           host_type
win7-32/64      Conroe, Penryn, Nehalem ,cpu64-rhel6 intel
win2003-32/64   Conroe, Penryn, Nehalem ,cpu64-rhel6 intel
rhel6-32/64     Conroe, Penryn, Nehalem ,cpu64-rhel6 intel
Fedora.12-32/64 Conroe, Penryn, Nehalem ,cpu64-rhel6 intel
win2003R2-32/64 Conroe, Penryn, Nehalem ,cpu64-rhel6 intel
win2008R2_64    Conroe, Penryn, Nehalem ,cpu64-rhel6 intel
Win2008-32/64   Conroe, Penryn, Nehalem ,cpu64-rhel6 intel

Tested on Host:
model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz


and the amd side,
the following guest can show correct cpu model as well:

Guest_OS_platform       guest_cpu                                host_type
win7-32/64       Opteron_G1, Opteron_G2, Opteron_G3 ,cpu64-rhel6 amd
win2003-32/64    Opteron_G1, Opteron_G2, Opteron_G3 ,cpu64-rhel6 amd
rhel6-32/64      Opteron_G1, Opteron_G2, Opteron_G3 ,cpu64-rhel6 amd
Fedora.12-32/64  Opteron_G1, Opteron_G2, Opteron_G3 ,cpu64-rhel6 amd
win2003R2-32/64  Opteron_G1, Opteron_G2, Opteron_G3 ,cpu64-rhel6 amd
Win2008R2_64     Opteron_G1, Opteron_G2, Opteron_G3 ,cpu64-rhel6 amd

host :
model name : Six-Core AMD Opteron(tm) Processor 2427

Comment 17 Xiaoqing Wei 2011-03-29 05:53:50 UTC
> Have you compared the behavior of the above windows guest to windows
> running on bare metal, when the same windows image is booted on
> different Opteron physical processors?  If the bare metal case shows
> the same suspect stale/cached cpuid data this may just be the normal
> behavior when the underlying cpu model changes underfoot.  Without
> knowing this I can't see a qemu/kvm problem to fix.


Hi,
I tried to install a win2k8 on a portable hard drive on a  Opteron_G3 host(bare metal). after install finished,boot the os and check cpu model,then switch to  Opteron_G1 host to check is it shows correct cpu model,but failed.seems win2k8 dont support install on a portable hard drive.

so tried to install it on a internal drive on  Opteron_G3 host then move the drive to  Opteron_G1 host,still fails.win2k8 failed to boot on different hard drive controller. 
can you give some advice to test that ?thx

Comment 18 john cooper 2011-04-09 01:37:50 UTC
(In reply to comment #17)
> > Have you compared the behavior of the above windows guest to windows
> > running on bare metal, when the same windows image is booted on
> > different Opteron physical processors?  If the bare metal case shows
> > the same suspect stale/cached cpuid data this may just be the normal
> > behavior when the underlying cpu model changes underfoot.  Without
> > knowing this I can't see a qemu/kvm problem to fix.
> 
> 
> Hi,
> I tried to install a win2k8 on a portable hard drive on a  Opteron_G3 host(bare
> metal). after install finished,boot the os and check cpu model,then switch to 
> Opteron_G1 host to check is it shows correct cpu model,but failed.seems win2k8
> dont support install on a portable hard drive.
> 
> so tried to install it on a internal drive on  Opteron_G3 host then move the
> drive to  Opteron_G1 host,still fails.win2k8 failed to boot on different hard
> drive controller. 
> can you give some advice to test that ?thx

Thinking about this further, I'm unsure this is actually a supported use
case:  switching the CPU model from boot to boot of a windows image.   Empirically windows intentionally caches the installed processor (and
perhaps as we see here, the current processor) type and features so it
can detect if a given windows installation has been moved elsewhere.  In
one scenario it uses this information to force a license reactivation.

For this reason alone I think we may be testing an unsupportable use case.

Comment 19 john cooper 2011-05-10 17:32:55 UTC
Closing this after further consideration as I don't believe
this is a realistic use case.  Notably just attempting this
could lead to windows reactivation.

Feel free to reopen if I've missed something however the
caching of prior CPU model is almost certainly occurring
within the windows guest utility.  If we can reproduce
this problem via either:

- under windows running a direct cpuid access utility (eg: x86info)

or

- under a linux guest

then we'd have something concrete to investigate.


Note You need to log in before you can comment on or make changes to this bug.