linux-kernel - Re: [PATCHv5 0/4] xen: maintain an accurate persistent clock in more cases

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: <51C36016.7010806@linaro.org>
Date:	Thu, 20 Jun 2013 13:03:34 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	David Vrabel <david.vrabel@...rix.com>
CC:	xen-devel@...ts.xen.org,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCHv5 0/4] xen: maintain an accurate persistent clock in more
 cases

On 06/20/2013 12:16 PM, David Vrabel wrote:
> Xen guests use the Xen wallclock as their persistent clock.  This is a
> software only clock in the hypervisor that is used by guests instead
> of a real hardware RTC.
>
> The kernel has limited support for updating the persistent clock or
> RTC when NTP is synced.  This has the following limitations:
>
> * The persistent clock is not updated on step changes.  This leaves a
>    window where it will be incorrect (while NTP resyncs).
>
> * Xen guests use the Xen wallclock as their persistent clock.  dom0
>    maintains this clock so it is persistent for domUs but not dom0
>    itself.
>
> These limitations mean that guests started before NTP is synchronized
> will start with an incorrect wallclock time and the hardware RTC will
> not be updated (as on bare metal).
>
> These series fixes the above limitations and depends on "x86: increase
> precision of x86_platform.get/set_wallclock()" which was previously
> posted.
>
> Changes since v4:
>
> Dropped the change to disable non-boot CPUs during suspend on Xen as
> migration downtime was too poor.  Instead, provide
> hrtimers_late_resume() for use by Xen's resume code to replace the
> call of clock_was_set().  Fix two unused variable warnings.

Ok, I've got these 4 in my pending stack. As long as Thomas doesn't 
object to the first two, and it doesn't run into any trouble in testing, 
I'll send them along for 3.12. (Acks from Xen maintainers would be nice 
for the last two as well).

Thanks for all the effort through all the revisions here!

thanks
-john

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