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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 17 Apr 2012 08:47:58 +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 19:30, Dan Magenheimer <dan.magenheimer@...cle.com> wrote:
>>  From: David Vrabel [mailto:david.vrabel@...rix.com]
>> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
>> 
>> On 16/04/12 17:05, Dan Magenheimer wrote:
>> >> From: David Vrabel [mailto:david.vrabel@...rix.com]
>> >> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
>> >
>> > Nacked-by: Dan Magenheimer <dan.magenheimer@...cle.com>
>> 
>> Fair enough,
>> 
>> > [A stable clock] should be true for Xen 4.0+ (but not for pre-Xen-4.0).
>> 
>> The original customer problem is on a host with Xen 3.4.  What do you
>> recommend for Linux guests running such hosts?
> 
> For pre-Xen-4.0 and an unchanged PV guest, I don't know.  If you can
> back-patch the guest kernel with a workaround such as your patch, great!
> I'm only arguing against the patch getting perpetuated upstream.
>  
>> > 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.
>> 
>> So, should the xen clocksource do:
>> 
>> if Xen 4.0+
>>     clock is stable, use rdtsc only.
>> else
>>     clock is unstable, use existing pvclock implementation.
> 
> Yes, that's what I propose.  To clarify:
> 
> if the guest can and does determine it is running on Xen 4.0+

_and_ TSC reads are emulated (which I don't think they are by
default).

Jan

> 	TSC is guaranteed by Xen to be stable, use clocksource=tsc tsc=reliable
> else
> 	Xen only guarantees that pvclock is stable, use pvclock


--
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/