From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752432AbbKLRRX (ORCPT ); Thu, 12 Nov 2015 12:17:23 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:21480 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751357AbbKLRRV (ORCPT ); Thu, 12 Nov 2015 12:17:21 -0500 Subject: Re: [PATCH v3 3/6] xen: introduce XENPF_settime64 To: Stefano Stabellini References: <1447260696-450-3-git-send-email-stefano.stabellini@eu.citrix.com> <5644B08F.9000205@oracle.com> Cc: xen-devel@lists.xensource.com, linux-arm-kernel@lists.infradead.org, Ian.Campbell@citrix.com, linux-kernel@vger.kernel.org, Arnd Bergmann , konrad.wilk@oracle.com, david.vrabel@citrix.com From: Boris Ostrovsky Message-ID: <5644C97F.7070502@oracle.com> Date: Thu, 12 Nov 2015 12:16:47 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/12/2015 11:34 AM, Stefano Stabellini wrote: > On Thu, 12 Nov 2015, Boris Ostrovsky wrote: >> On 11/11/2015 11:51 AM, Stefano Stabellini wrote: >>> Rename the current XENPF_settime hypercall and related struct to >>> XENPF_settime32. >>> >>> Signed-off-by: Stefano Stabellini >>> Acked-by: Arnd Bergmann >>> CC: konrad.wilk@oracle.com >>> CC: david.vrabel@citrix.com >>> CC: boris.ostrovsky@oracle.com >>> --- >>> arch/x86/xen/time.c | 8 ++++---- >>> include/xen/interface/platform.h | 18 ++++++++++++++---- >>> 2 files changed, 18 insertions(+), 8 deletions(-) >>> >>> 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). > I can do that, but it should be a separate patch. I'll queue it at the > end of the series. Didn't Arnd just say that something needs to be done in the hypervisor for that to work? Or did I misunderstood him? Anyway, for this patch Reviewed-by: Boris Ostrovsky > > >>> (void)HYPERVISOR_platform_op(&op); >>> diff --git a/include/xen/interface/platform.h >>> b/include/xen/interface/platform.h >>> index 8e03587..732efb0 100644 >>> --- a/include/xen/interface/platform.h >>> +++ b/include/xen/interface/platform.h >>> @@ -35,14 +35,23 @@ >>> * Set clock such that it would read after 00:00:00 UTC, >>> * 1 January, 1970 if the current system time was . >>> */ >>> -#define XENPF_settime 17 >>> -struct xenpf_settime { >>> +#define XENPF_settime32 17 >>> +struct xenpf_settime32 { >>> /* IN variables. */ >>> uint32_t secs; >>> uint32_t nsecs; >>> uint64_t system_time; >>> }; >>> -DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime_t); >>> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime32_t); >>> +#define XENPF_settime64 62 >>> +struct xenpf_settime64 { >>> + /* IN variables. */ >>> + uint64_t secs; >>> + uint32_t nsecs; >>> + uint32_t mbz; >>> + uint64_t system_time; >>> +}; >>> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime64_t); >>> /* >>> * Request memory range (@mfn, @mfn+@nr_mfns-1) to have type @type. >>> @@ -495,7 +504,8 @@ struct xen_platform_op { >>> uint32_t cmd; >>> uint32_t interface_version; /* XENPF_INTERFACE_VERSION */ >>> union { >>> - struct xenpf_settime settime; >>> + struct xenpf_settime32 settime32; >>> + struct xenpf_settime64 settime64; >>> struct xenpf_add_memtype add_memtype; >>> struct xenpf_del_memtype del_memtype; >>> struct xenpf_read_memtype read_memtype; From mboxrd@z Thu Jan 1 00:00:00 1970 From: boris.ostrovsky@oracle.com (Boris Ostrovsky) Date: Thu, 12 Nov 2015 12:16:47 -0500 Subject: [PATCH v3 3/6] xen: introduce XENPF_settime64 In-Reply-To: References: <1447260696-450-3-git-send-email-stefano.stabellini@eu.citrix.com> <5644B08F.9000205@oracle.com> Message-ID: <5644C97F.7070502@oracle.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 11/12/2015 11:34 AM, Stefano Stabellini wrote: > On Thu, 12 Nov 2015, Boris Ostrovsky wrote: >> On 11/11/2015 11:51 AM, Stefano Stabellini wrote: >>> Rename the current XENPF_settime hypercall and related struct to >>> XENPF_settime32. >>> >>> Signed-off-by: Stefano Stabellini >>> Acked-by: Arnd Bergmann >>> CC: konrad.wilk at oracle.com >>> CC: david.vrabel at citrix.com >>> CC: boris.ostrovsky at oracle.com >>> --- >>> arch/x86/xen/time.c | 8 ++++---- >>> include/xen/interface/platform.h | 18 ++++++++++++++---- >>> 2 files changed, 18 insertions(+), 8 deletions(-) >>> >>> 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). > I can do that, but it should be a separate patch. I'll queue it at the > end of the series. Didn't Arnd just say that something needs to be done in the hypervisor for that to work? Or did I misunderstood him? Anyway, for this patch Reviewed-by: Boris Ostrovsky > > >>> (void)HYPERVISOR_platform_op(&op); >>> diff --git a/include/xen/interface/platform.h >>> b/include/xen/interface/platform.h >>> index 8e03587..732efb0 100644 >>> --- a/include/xen/interface/platform.h >>> +++ b/include/xen/interface/platform.h >>> @@ -35,14 +35,23 @@ >>> * Set clock such that it would read after 00:00:00 UTC, >>> * 1 January, 1970 if the current system time was . >>> */ >>> -#define XENPF_settime 17 >>> -struct xenpf_settime { >>> +#define XENPF_settime32 17 >>> +struct xenpf_settime32 { >>> /* IN variables. */ >>> uint32_t secs; >>> uint32_t nsecs; >>> uint64_t system_time; >>> }; >>> -DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime_t); >>> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime32_t); >>> +#define XENPF_settime64 62 >>> +struct xenpf_settime64 { >>> + /* IN variables. */ >>> + uint64_t secs; >>> + uint32_t nsecs; >>> + uint32_t mbz; >>> + uint64_t system_time; >>> +}; >>> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime64_t); >>> /* >>> * Request memory range (@mfn, @mfn+ at nr_mfns-1) to have type @type. >>> @@ -495,7 +504,8 @@ struct xen_platform_op { >>> uint32_t cmd; >>> uint32_t interface_version; /* XENPF_INTERFACE_VERSION */ >>> union { >>> - struct xenpf_settime settime; >>> + struct xenpf_settime32 settime32; >>> + struct xenpf_settime64 settime64; >>> struct xenpf_add_memtype add_memtype; >>> struct xenpf_del_memtype del_memtype; >>> struct xenpf_read_memtype read_memtype;