Bug 549264
Summary: | Export nonstop_tsc to the guest on an host without it | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | jason wang <jasowang> | ||||||
Component: | kernel | Assignee: | Prarit Bhargava <prarit> | ||||||
Status: | CLOSED NOTABUG | QA Contact: | Red Hat Kernel QE team <kernel-qe> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 5.6 | CC: | john.cooper, llim, tburke, virt-maint, ykaul, zamsden | ||||||
Target Milestone: | rc | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2011-01-20 19:05:15 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: | |||||||||
Bug Blocks: | 580948 | ||||||||
Attachments: |
|
Description
jason wang
2009-12-21 04:48:28 UTC
Unsure whether this is an issue of qemu passing bad data or the guest kernel incorrectly interpreting the flag. Could you run: # x86info -a -f on both host and guest and attach a log of the output? If needed you can find a binary of the utility here: http://people.redhat.com/~jcooper/cpuid/utils/x86info/x86info-1.24/x86info Can I get a pointer to the host/guest install images used to create the above test scenario? Created attachment 383185 [details]
x86info log on the guest
Created attachment 383187 [details]
x86info log on the host
Hello john: I've used the x86info at http://www.codemonkey.org.uk/projects/x86info/ because the link your show me does not work under 32bit guest. And during the execution in guest, the following warning could be found: /dev/cpu/0/msr: No such file or directory The log have been attached. Hello john: I've reproduced this problem in root@654321:10.66.85.201, and the 32bit RHEL image could be found at /tmp/kvm_autotest_root/images. This may be a false positive. The TscInvariant flag is defined as fn 0x8000_0007: edx & 0x00000100 which isn't set on host nor guest as reported by x86info: $ grep -r 80000007 /tmp/x86info.* /tmp/x86info.guest:eax in: 0x80000007, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 /tmp/x86info.host:eax in: 0x80000007, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 0000007f /tmp/x86info.host:eax in: 0x80000007, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 0000007f Don't know why the guest kernel is reporting it in /proc/cpuinfo. Can you send me login info to 10.66.85.201? Hello john: You could use root as the user and 654321 as the password to log into 10.66.85.201. Appears to be a possible quirk in the guest kernel as direct cpuid access via x86info shows TscInvariant not to be set (as above). Not dismissing the case outright until further investigation but moving to 5.6 as a non-blocker per Dor's request. This bug is deeply confused; the hypervisor doesn't export nonstop_tsc field, this is determined by the guest. Additionally, the original poster was tweaking the CPU type with qemu, which caused the nonstop_tsc flag to be turned on when it shouldn't have been. However, note that under kvm, nonstop_tsc should be true since the TSC virtualization should never stop. It's actually really minor, as nonstop_tsc isn't actually used for anything other than a flag to userspace. I think it's safe to close. |