linux-kernel - RE: [Xen-devel] [PATCH] xen: always set the sched clock as unstable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <4F8C619C020000780007E34E@nat28.tlf.novell.com>
Date:	Mon, 16 Apr 2012 17:14:52 +0100
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"David Vrabel" <david.vrabel@...rix.com>,
	"Dan Magenheimer" <dan.magenheimer@...cle.com>
Cc:	"Thomas Gleixner" <tglx@...utronix.de>,
	"xen-devel" <xen-devel@...ts.xen.org>,
	"Konrad Wilk" <konrad.wilk@...cle.com>,
	<linux-kernel@...r.kernel.org>, "Tim (Xen.org)" <tim@....org>,
	"Sheng Yang" <sheng@...ker.org>
Subject: RE: [Xen-devel] [PATCH] xen: always set the sched clock as
 unstable

>>> On 16.04.12 at 18:05, Dan Magenheimer <dan.magenheimer@...cle.com> wrote:
>>  From: David Vrabel [mailto:david.vrabel@...rix.com]
>> On 16/04/12 12:32, Jan Beulich wrote:
>> >>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@...rix.com> wrote:
>> >> --- a/arch/x86/xen/time.c
>> >> +++ b/arch/x86/xen/time.c
>> >> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
>> >>  	do_settimeofday(&tp);
>> >>
>> >>  	setup_force_cpu_cap(X86_FEATURE_TSC);
>> >> +	sched_clock_stable = 0;
>> >
>> > This, unfortunately, is not sufficient afaict: If a CPU gets brought up
>> > post-boot, the variable may need to be cleared again. Instead you
>> > ought to call mark_tsc_unstable().
>> 
>> Yeah, mark_tsc_unstable() is the right thing to do.
> 
> NACK!
> 
> No, no, no.  The exact opposite is true.  Like VMware, TSC is
> stable.  The issue is that Linux trusts other clock hardware more
> completely than TSC so whenever there is a problem with another
> clocksource, Linux blames TSC and marks TSC unstable.  But TSC
> on Xen 4.0+ is innocent.  In fact, TSC is a better clocksource
> choice than clocksource=xen (aka pvclock) because pvclock
> indirectly depends on TSC.
> 
> For upstream kernels, the answer is to set clocksource=tsc
> and tsc=reliable, like VMware enforces. See:
> 
> https://lists.ubuntu.com/archives/kernel-team/2008-October/004283.html 
> 
> In fact, it might be wise for a Xen-savvy kernel to check to see
> if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> and tsc=reliable.

Are you possibly mixing up PV and HVM cases? sched_clock_stable
getting set _is_ a problem in PV kernels - we had bug reports long
ago when this first appeared in arch/x86/kernel/cpu/intel.c. I'm
suspecting this because there's not supposed to be (and in non-
pv-ops there is no; in pv-ops I assume it simply has no effect)
clocksource=tsc in PV kernels.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/