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: <cab53fa9-398f-4e06-885f-c388a9ea3c29@default>
Date:	Mon, 16 Apr 2012 09:20:26 -0700 (PDT)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Konrad Wilk <konrad.wilk@...cle.com>,
	David Vrabel <david.vrabel@...rix.com>
Cc:	"Tim (Xen.org)" <tim@....org>, linux-kernel@...r.kernel.org,
	xen-devel <xen-devel@...ts.xen.org>,
	Jan Beulich <JBeulich@...e.com>, Sheng Yang <sheng@...ker.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: RE: [Xen-devel] [PATCH] xen: always set the sched clock as unstable

> From: Konrad Rzeszutek Wilk
> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> 
> On Mon, Apr 16, 2012 at 03:59:44PM +0100, David Vrabel wrote:
> > On 16/04/12 12:32, Jan Beulich wrote:
> > >>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@...rix.com> wrote:
> > >> From: David Vrabel <david.vrabel@...rix.com>
> > >>
> > >> The sched clock was considered stable based on the capabilities of the
> > >> underlying hardware.  This does not make sense for Xen PV guests as:
> 
> In regards to PV dom0 is this still the case? Asking b/c your
> patch will make dom0 be in the same category.
> 
> > >> a) the hardware TSC is not used directly as the clock source; and b)
> > >> guests may migrate to hosts with different hardware capabilities.
> > >>
> > >> It is not clear to me whether the Xen clock source is supposed to be
> > >> stable and whether it should be stable across migration.  For a clock

Xen is -- and has always been -- responsible for emulating sufficient
clock hardware devices and presenting them to the guest AND ensuring
that this emulation works properly across migration/save/restore (which
is required because these transitions may be completely transparent
to the guest).

Prior to Xen 4.0, TSC was not considered to be a clocksource worthy
of emulating and was passed through to PV guests unchanged (and not
fully handled for HVM either IIRC).  At Xen 4.0+, it is handled properly.
 
> I thought it was dependent on XEN_DOMCTL_settscinfo:
>  - whether it gets emulated, or the guest can do rdtsc or pvrdtsc?
>
> Which I think is determined by some 'timer=X' option in the guest config?

I think you may be thinking of tsc_mode.  See docs/misc/tscmode.txt
in the Xen source.  The default should work correctly.

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