Bug 606246
Summary: | TSC is not synchronized between VCPUs | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | YangFeng <fyang> |
Component: | kvm | Assignee: | Zachary Amsden <zamsden> |
Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 5.7 | CC: | gcosta, llim, michen, mkenneth, mtosatti, riel, shuang, tburke, virt-maint, ykaul |
Target Milestone: | rc | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-02-07 14:02:04 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: | 562808, 580946, 580948 |
Description
YangFeng
2010-06-21 08:26:47 UTC
*** Bug 647106 has been marked as a duplicate of this bug. *** This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. This request was erroneously denied for the current release of Red Hat Enterprise Linux. The error has been fixed and this request has been re-proposed for the current release. The fixes for this are upstream and should be backported to RHEL 5. Note that this is not fixed by TSC trapping. This is related to TSC getting out of sync in the guest during CPU power on, reset, and when the guest attempts to reprogram the TSC itself. Cc-ing reviewers of my RHEL6 TSC patches. After attempting to port this patch series back to RHEL5, it became apparent there was more missing infrastructure, one problem is that RHEL5 does not detect CPU frequency changes and reflect them in kvmclock at all. The result is the patch series would need to introduce more changes. While it is possible to do, there is added risk involved and the benefits are +/- from upstream. One benefit is that one of the changes (fix a possible backwards warp of kvmclock) actually has much greater benefit (due to lack of fine grained clocksources in RHEL5, the bug window is higher). However, the infrastructure work which was done in these patches in preparation for future changes (tsc trapping / scaling) is not needed (again due to lack of fine grained clocksources, those changes will not be very effective on a RHEL5 kernel base). It's not really possible to bring the fine grained clocksources to RHEL5, that requires a significant and risky kernel change that I'm not willing to do on a stable release. So there is mixed benefit, some risks, and as far as I know, not a lot of complaints about the TSC or kvmclock on RHEL5. My suggestion is to not backport these changes to RHEL5 unless we really think they are needed. One exception might be that backwards warp fix, which could provide some benefit; other than that, I'd like to avoid unnecessary changes here. I'm seeking feedback from the patch reviewers on that, as they are in a better position than others to assess risk. Agreed, we need to limit the risk in RHEL 5, even if it means leaving certain bugs in place. The few people who are affected by unstable TSCs on certain multi-core AMD systems have the option of migrating to RHEL 6. To risk breaking the timer for everybody else just is not worth it, IMHO. There's not much we can do to fix this problem in RHEL5 without substantial risk. If we ever see TSC going backwards on RHEL5 in a UP environment, there may be some steps we can take to correct that, but without a reported bug, I'm skeptical to cherry pick the one fix needed for that - especially as it only helps in very narrow cases - unstable host TSC and migration - which already have other, even deeper issues with TSC (SMP stability and scaling problems). Since KVM clock should address all of those problems on RHEL5 and we have an upgrade path in place for RHEL6, our exposure on this issue is very limited. Closing wontfix. |