From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754902AbbKLQKr (ORCPT ); Thu, 12 Nov 2015 11:10:47 -0500 Received: from mout.kundenserver.de ([212.227.126.131]:52691 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752152AbbKLQKq (ORCPT ); Thu, 12 Nov 2015 11:10:46 -0500 From: Arnd Bergmann To: Boris Ostrovsky Cc: Stefano Stabellini , xen-devel@lists.xensource.com, linux-arm-kernel@lists.infradead.org, Ian.Campbell@citrix.com, linux-kernel@vger.kernel.org, konrad.wilk@oracle.com, david.vrabel@citrix.com Subject: Re: [PATCH v3 3/6] xen: introduce XENPF_settime64 Date: Thu, 12 Nov 2015 17:10:07 +0100 Message-ID: <6642964.WydNcvXaCu@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <5644B08F.9000205@oracle.com> References: <1447260696-450-3-git-send-email-stefano.stabellini@eu.citrix.com> <5644B08F.9000205@oracle.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:LvNJ3TQLlXYXaoVYMzNLrSy8W0yg6jvpQYVRg5uXI0qI1pFrT5g gmZEmBtxPjJCtwOpfbdWRzGWwPFuG05FWf0CKbERCAk2p/Xs+lkwRc2nyCVXvLVN55OcsME oCylTxd+JMeV5MQuhW3ApQtk3GSt933JZbON89qQP/ZTwFTutJvR59FKBfQouEtk8/SM1+f B62B2XWxocyM1eLWUjSiA== X-UI-Out-Filterresults: notjunk:1;V01:K0:uX0HZcH37Vw=:akz0qPEG5jA3bhFVVC8jQV aoeYI/HTO69ak4NnDGj3L85aZcqujG8tovAorX0aXUMXH7OuGIQlN3DULP+/XgB0VOBwz0fyQ +6CCZ5lCGQrSuE4m93YZvZyZhI3DiQNETAE+uA3E9T6sXYE7pgrngGm8T+NHP68SwpB6hQruJ hdxLs/h2eNUtdcsvbc48IoKkdXxKNeGA2Ty1hOoQjMohWv4tVV+Ktx+AUmV199aXjvOO0nQj6 rVLzbogQiAK6NLVOg8PI462ZpHIjE5K7OyElXywus8BbmJSC4JmJPyyQeXtqotmsABD/lAc5M RApNMlQsAfAr3PUv/ew7lD7s+EqNrjHAqnaTdAQLws7OSom0PipphziprPLnmabfaxGtQqjt2 eh3shG0tv4t+X/M9Yw8fouxK60Zd9K19Q9px0Bk2LBfFls8riu5PbGi10UqqjU/ILA+nggL8i /iO4v4jcK9aSmjE9Es+19B8Qgf3zEDTct3176ewygucJn9F24SN/qQYDqRfgUYs5BwZl+mAYq CC83Kk6sN38Xwqu+FHjjIF/FMRcBtsE3YHXhGAQj5bWi9S2R78+226r58g/q5Vwbj2eVODHHM koPDmQbnvA4IrBkKd/PNI5tKdvN7egxwEtlrps95cS3yDI1ViBvYAsiFErOHYzbGPqKZExefo Q45P78+cdqpqLtf0bCx+8n7RVp1rsmmQtMa2cwdmuMl1EuBn653Fpa2CJIDC3tr6EmN1glrsk 8iJMLZBkobsNfd0N Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 12 November 2015 10:30:23 Boris Ostrovsky wrote: > > diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c > > index 663c2ea..3bbd377 100644 > > --- a/arch/x86/xen/time.c > > +++ b/arch/x86/xen/time.c > > @@ -134,10 +134,10 @@ static int xen_pvclock_gtod_notify(struct notifier_block *nb, > > if (!was_set && timespec_compare(&now, &next_sync) < 0) > > return NOTIFY_OK; > > > > - op.cmd = XENPF_settime; > > - op.u.settime.secs = now.tv_sec; > > - op.u.settime.nsecs = now.tv_nsec; > > - op.u.settime.system_time = xen_clocksource_read(); > > + op.cmd = XENPF_settime32; > > + op.u.settime32.secs = now.tv_sec; > > + op.u.settime32.nsecs = now.tv_nsec; > > + op.u.settime32.system_time = xen_clocksource_read(); > > Can/should we switch to time64 here? (This would require a couple more > changes but they would all be local to this routine). We definitely should. We are in the process of removing all uses of timespec from the kernel in favor of timespec64, and this requires changing the Xen code as well if we want to do it right. I suppose that both Dom0 and DomU will have to support the old and the new interface for x86, so we have a fallback if the 64-bit interface fails. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Thu, 12 Nov 2015 17:10:07 +0100 Subject: [PATCH v3 3/6] xen: introduce XENPF_settime64 In-Reply-To: <5644B08F.9000205@oracle.com> References: <1447260696-450-3-git-send-email-stefano.stabellini@eu.citrix.com> <5644B08F.9000205@oracle.com> Message-ID: <6642964.WydNcvXaCu@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thursday 12 November 2015 10:30:23 Boris Ostrovsky wrote: > > diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c > > index 663c2ea..3bbd377 100644 > > --- a/arch/x86/xen/time.c > > +++ b/arch/x86/xen/time.c > > @@ -134,10 +134,10 @@ static int xen_pvclock_gtod_notify(struct notifier_block *nb, > > if (!was_set && timespec_compare(&now, &next_sync) < 0) > > return NOTIFY_OK; > > > > - op.cmd = XENPF_settime; > > - op.u.settime.secs = now.tv_sec; > > - op.u.settime.nsecs = now.tv_nsec; > > - op.u.settime.system_time = xen_clocksource_read(); > > + op.cmd = XENPF_settime32; > > + op.u.settime32.secs = now.tv_sec; > > + op.u.settime32.nsecs = now.tv_nsec; > > + op.u.settime32.system_time = xen_clocksource_read(); > > Can/should we switch to time64 here? (This would require a couple more > changes but they would all be local to this routine). We definitely should. We are in the process of removing all uses of timespec from the kernel in favor of timespec64, and this requires changing the Xen code as well if we want to do it right. I suppose that both Dom0 and DomU will have to support the old and the new interface for x86, so we have a fallback if the 64-bit interface fails. Arnd