From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: Debian stable kernel got timer issue when running as PV guest Date: Fri, 13 Apr 2012 17:10:45 +0100 Message-ID: <4F885005.7090605@citrix.com> References: <4F87F84B020000780007DB52@nat28.tlf.novell.com> <4F8801DD.4030004@cantab.net> <4F882381020000780007DC4C@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F882381020000780007DC4C@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Sheng Yang , jeremy@goop.org, keir@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 13/04/12 12:00, Jan Beulich wrote: >>>> On 13.04.12 at 12:37, David Vrabel wrote: >> On 13/04/12 08:56, Jan Beulich wrote: >>>>>> On 12.04.12 at 21:22, Sheng Yang wrote: >>>> I've compiled a kernel, force sched_clock_stable=0, then it solved the >>>> timestamp jump issue as expected. Luckily, seems it also solved the call >>>> trace and guest hang issue as well. >>> >>> And this is also how it should be fixed. >> >> Something like this? I've not tested it yet as I need to track down >> some of the problem hardware and get it set up. > > Yeah, except that I'm not sure you really need to clear the feature > flags. Just making sure sched_clock_stable never gets set should be > enough; playing with the feature flags always implies that users will > see bigger differences in /proc/cpuinfo between native and Xen > kernels... I have a system with both NONSTOP_TSC and CONSTANT_TSC so sched_clock_stable should be true. VMs start and migrate fine with no unexpected jumps in time. I think more digging is required here to find out why time is screwy on this particular system. David >> 8<--------------- >> xen: always set the sched clock as unstable >> >> It's not clear to me if the Xen clock source can be used as a stable >> sched clock. Also, even if the guest is started on a system whose >> underying TSC is stable it may be migrated to one where it's not. So >> never mark the sched clock as stable. >> >> Signed-off-by: David Vrabel >> --- >> arch/x86/xen/time.c | 3 +++ >> 1 files changed, 3 insertions(+), 0 deletions(-) >> >> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c >> index 0296a95..b22cd9c 100644 >> --- a/arch/x86/xen/time.c >> +++ b/arch/x86/xen/time.c >> @@ -473,6 +473,9 @@ static void __init xen_time_init(void) >> do_settimeofday(&tp); >> >> setup_force_cpu_cap(X86_FEATURE_TSC); >> + setup_clear_cpu_cap(X86_FEATURE_CONSTANT_TSC); >> + setup_clear_cpu_cap(X86_FEATURE_NONSTOP_TSC); >> + sched_clock_stable = 0; >> >> xen_setup_runstate_info(cpu); >> xen_setup_timer(cpu);