https://bugzilla.novell.com/show_bug.cgi?id=623680
https://bugzilla.novell.com/show_bug.cgi?id=623680#c59
--- Comment #59 from Jan Beulich
Hm, the whole point of this bug report (for me) was to enable C2/C3 on this machine :-(
Sort of contrary to the bug title...
If I am reading the code correctly, the main difference between Xen and Linux is that Linux completely avoids using the TSC where it is unstable or otherwise unreliable. Xen, OTOH, always uses TSC, and just uses the "platform timer" to calibrate and adjust TSC when it isn't stable.
Correct. (In reply to comment #58)
Just a very crude idea: On CPUs such as mine, where writing the TSC zeroes out the upper 32bits, wouldn't it be possible to treat the TSC as a 32bit timer only? Similar code is already in place for the 32bit and 24bit platform timers.
Here you sort of contradict your own observations noted in the previous comment: The platform timer is used for calibration, and an overflow timer is used as a helper to deal with it being narrow. The TSC, otoh, is the main timer, and hence treating it as a 32-bit counter would involve quite some more changes (but it's certainly doable afaict). Since the (64-bit) TSC is part of the hypervisor/kernel interface, running *all* guests (including Dom0) with emulated rdtsc would be a direct consequence. In any case, your machine not dying anymore is where we'll have to end this. Enabling C2/C3 on such systems would (as far as we're concerned) presumably be an enhancement request, not a bug report, and hence would be expected to get addressed upstream first. So if you can talk anyone into doing this work, or if you want to give this a try yourself... One thing you might try though is whether at least C2 can be used on your system ("lapic_timer_c2_ok" on the Xen command line if the APIC timer doesn't stop in C2, similar to the identical native Linux option). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.