On Wed, 30 Nov 2016 00:22:41 -0500 Alan Altmark <[email protected]> wrote:
> On Tuesday, 11/29/2016 at 08:56 GMT, Aria Bamdad <[email protected]> wrote: > > When you say the virtual TOD is on UTC, do you mean that even if I IPL > > z/VM using > > the local time and timezone, the TOD reported to Linux is in UTC? > > Then this means > > regardless of what z/VM time is set to, the guests always see UTC as > > the TOD time. > > Unless you use CP SET VTOD command or the guest issues a SET CLOCK or > PERFORM TIMING FACILITY FUNCTION instruction to change the virtual TOD, > the virtual TOD will match the LPAR TOD. Further, the LPAR TOD will match > the machine TOD. I'm over-simplifying, but it's good enough for our > discussion. Linux uses the only available source to get the initial time which is the TOD clock. The assumption is that the wall clock returned by the TOD is STP time. If you configure your machine by the book the following holds: STP timestamp = UTC timestamp + leap-second-offset As Alan already mentioned most people simply use UTC for the TOD clock and ignore leap seconds. In this case the time stamp returned by the TOD clock is UTC. The Linux time is calculated in UTC, any timezone offset is added by userspace. Now we have three cases: 1) TOD = UTC with leap seconds. The initial system time is UTC. All is good. 2) TOD = UTC without leap seconds. The initial system time is UTC + leap-seconds. The initial system time is off by the number of leap seconds. 3) TOD = local time Linux has no way to know what you did to your machine TOD clock. The initial system time will by off by the timezone offset. There is an upstream patch to read the configured number of leap seconds at IPL and subtract it from the TOD clock to get the initial time. This fixes case 2). See the following git commit: commit 936cc855ffe808b428cf75116fe031af9f12237e Author: Martin Schwidefsky <[email protected]> Date: Tue May 31 12:47:03 2016 +0200 s390/time: add leap seconds to initial system time The PTFF instruction can be used to retrieve information about UTC including the current number of leap seconds. Use this value to convert the coordinated server time value of the TOD clock to a proper UTC timestamp to initialize the system time. Without this correction the system time will be off by the number of leap seonds until it has been corrected via NTP. Signed-off-by: Martin Schwidefsky <[email protected]> This is upstream only right now. > > Based on the above, I tested setting the correct region, and then > > selected 'Hardware > > clock set to UTC' in Yast and rebooted. Sure enough, the time in > > Linux shows my local > > time correctly. > > > > So does this mean that regardless of what z/VM time is set to, the > > Linux guests should > > select their time as 'Hardware clock set to UTC'? > > Before Linux can correctly calculate the time, it needs to know how the > (virtual) TOD clock is set. Some people (unwisely) set the TOD clock to > the local time instead of UTC by setting local time with offset 0 (gag). > But most people set the TOD clock to UTC (ignoring leap seconds). If you do that the only way to get your system time corrected is NTP. > > Is the kernel parameter clocksource=tod needed? > > I don't think so, but I'm not sure. A long time ago the timer support in > Linux was changed to use the TOD rather than depending on a ticking > software clock. (Martin?) No, you do not have to do this. There is only one clocksource which is the TOD and it is used automatically. My suggestion would by to configure your machines TOD clock to UTC. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
