Bug 682189
Summary: | win2k8 32bit shows incorrect cpu model when on amd host | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Xiaoqing Wei <xwei> |
Component: | qemu-kvm | Assignee: | john cooper <john.cooper> |
Status: | CLOSED NOTABUG | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.1 | CC: | juzhang, mkenneth, nobody, shuang, tburke, virt-maint |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Windows | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-05-10 17:32:55 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 580954 | ||
Bug Blocks: | |||
Attachments: |
Description
Xiaoqing Wei
2011-03-04 11:50:50 UTC
Created attachment 482277 [details]
snapshots
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 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. (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 Created attachment 482858 [details]
boot the guest with G2,and it shows G3(the previous cpu use to boot the guest)
Created attachment 482859 [details]
boot the guest with G2,and it shows G3(the previous cpu use to boot the guest)
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. (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. Created attachment 483659 [details]
"computer's properties " displaying correct model while 'device manager' showing incorrect model
Seems like to a real qemu/kvm bug to me. It might be an issue an windows or not. Can we close it? (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? 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 (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. (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 ? 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
> 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
(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. 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. |