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]

Message-ID: <20120416170827.GE13111@ocelot.phlegethon.org>
Date:	Mon, 16 Apr 2012 18:08:27 +0100
From:	Tim Deegan <tim@....org>
To:	Dan Magenheimer <dan.magenheimer@...cle.com>
Cc:	David Vrabel <david.vrabel@...rix.com>,
	Jan Beulich <JBeulich@...e.com>,
	Konrad Wilk <konrad.wilk@...cle.com>,
	linux-kernel@...r.kernel.org, xen-devel <xen-devel@...ts.xen.org>,
	Sheng Yang <sheng@...ker.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable

At 09:05 -0700 on 16 Apr (1334567132), Dan Magenheimer wrote:
> Hmmm... I spent a great deal of time on TSC support in the hypervisor
> 2-3 years ago.  I worked primarily on PV, but Intel supposedly was tracking
> everything on HVM as well.  There's most likely a bug or two still lurking
> but, for all guests, with the default tsc_mode, TSC is provided by Xen
> as an absolutely stable clock source.  If Xen determines that the underlying
> hardware declares that TSC is stable, guest rdtsc instructions are not trapped.
> If it is not, Xen emulates all guest rdtsc instructions.  After a migration or
> save/restore, TSC is always emulated.  The result is (ignoring possible
> bugs) that TSC as provided by Xen is a) monotonic; b) synchronized across
> CPUs; and c) constant rate.  Even across migration/save/restore.

AIUI, this thread is about the PV-time clock source, not about the TSC
itself.  Even if the TSC is emulated (or in some other way made
"stable") the PV wallclock is not necessarily stable across migration.
But since migration is controlled by the kernel, presumably the kernel
can DTRT about it.

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

That seems like overdoing it.  Certainly it's not OK unless it can also
check that Xen is providing a stable TSC (i.e. that tscmode==1).

In the case where the PV clock has been selected, can it not be marked
unstable without also marking the TSC unstable?

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