All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Juergen Gross <jgross@suse.com>,
	Joao Martins <joao.m.martins@oracle.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	xen-devel@lists.xenproject.org, kvm@vger.kernel.org,
	y2038@lists.linaro.org, Jan Kiszka <jan.kiszka@siemens.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	jailhouse-dev@googlegroups.com, Ingo Molnar <mingo@redhat.com>,
	John Stultz <john.stultz@linaro.org>,
	Borislav Petkov <bp@suse.de>, Andy Lutomirski <luto@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH] [v3] x86: Convert x86_platform_ops to timespec64
Date: Fri, 27 Apr 2018 22:56:22 +0200	[thread overview]
Message-ID: <20180427205621.GE23874__31110.9028793455$1524862527$gmane$org@flask> (raw)
In-Reply-To: <20180427201435.3194219-1-arnd@arndb.de>

2018-04-27 22:13+0200, Arnd Bergmann:
> The x86 platform operations are fairly isolated, so we can
> change them from using timespec to timespec64. I checked that
> All the users and callers are safe, and there is only one
> critical function that is broken beyond 2106:
> 
> pvclock_read_wallclock() uses a 32-bit number of seconds since
> the epoch to communicate the boot time between host and guest
> in a virtual environment. This will work until 2106, but we
> should ideally find a replacement anyway. I've added a comment
> about it there.
> 
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v2 changes:
> - move comment block (Boris)
> - remove unnecessary type cast (Boris)
> - fix format string (0day bot)
> - fix include order (0day bot)
> 
> v3 changes:
> - add jailhouse specific change
> - avoid include file header by relying on another
>   patch ("timekeeping: Remove timespec64 hack")
> 
> Not sure how we want to merge this (assuming the last modification
> worked, this has seen little testing). The "timekeeping: Remove
> timespec64 hack" patch should go through the timekeeping branch
> in tip, while this one is for x86. I assume the linux-tip maintainers
> can come up with a plan.
> ---
> diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
> @@ -12,7 +12,7 @@ void pvclock_set_flags(u8 flags);
>  unsigned long pvclock_tsc_khz(struct pvclock_vcpu_time_info *src);
>  void pvclock_read_wallclock(struct pvclock_wall_clock *wall,
>  			    struct pvclock_vcpu_time_info *vcpu,
> -			    struct timespec *ts);
> +			    struct timespec64 *ts);
>  void pvclock_resume(void);
>  
>  void pvclock_touch_watchdogs(void);
> diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
> @@ -53,7 +53,7 @@ static struct pvclock_wall_clock *wall_clock;
>   * have elapsed since the hypervisor wrote the data. So we try to account for
>   * that with system time
>   */
> -static void kvm_get_wallclock(struct timespec *now)
> +static void kvm_get_wallclock(struct timespec64 *now)
>  {
>  	struct pvclock_vcpu_time_info *vcpu_time;
>  	int low, high;
> @@ -72,7 +72,7 @@ static void kvm_get_wallclock(struct timespec *now)
>  	put_cpu();
>  }
>  
> -static int kvm_set_wallclock(const struct timespec *now)
> +static int kvm_set_wallclock(const struct timespec64 *now)
>  {
>  	return -ENODEV;
>  }
> diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
> @@ -123,28 +123,35 @@ u64 pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
>  
>  void pvclock_read_wallclock(struct pvclock_wall_clock *wall_clock,
>  			    struct pvclock_vcpu_time_info *vcpu_time,
> -			    struct timespec *ts)
> +			    struct timespec64 *ts)
>  {
>  	u32 version;
>  	u64 delta;
> -	struct timespec now;
> +	struct timespec64 now;
>  
>  	/* get wallclock at system boot */
>  	do {
>  		version = wall_clock->version;
>  		rmb();		/* fetch version before time */
> +		/*
> +		 * Note: wall_clock->sec is a u32 value, so it can
> +		 * only store dates between 1970 and 2106. To allow
> +		 * times beyond that, we need to create a new hypercall
> +		 * interface with an extended pvclock_wall_clock structure
> +		 * like ARM has.
> +		 */

(Modern TSC extensions stripped pvclock of all advantages, so we'll
 likely abandon pvclock by then.)

>  		now.tv_sec  = wall_clock->sec;
>  		now.tv_nsec = wall_clock->nsec;
>  		rmb();		/* fetch time before checking version */
>  	} while ((wall_clock->version & 1) || (version != wall_clock->version));
>  
>  	delta = pvclock_clocksource_read(vcpu_time);	/* time since system boot */
> -	delta += now.tv_sec * (u64)NSEC_PER_SEC + now.tv_nsec;
> +	delta += now.tv_sec * NSEC_PER_SEC + now.tv_nsec;
>  
>  	now.tv_nsec = do_div(delta, NSEC_PER_SEC);
>  	now.tv_sec = delta;
>  
> -	set_normalized_timespec(ts, now.tv_sec, now.tv_nsec);
> +	set_normalized_timespec64(ts, now.tv_sec, now.tv_nsec);
>  }
>  
>  void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti)

kvmclock and pvclock changes

Acked-by: Radim Krčmář <rkrcmar@redhat.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-04-27 20:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-27 20:13 [PATCH] [v3] x86: Convert x86_platform_ops to timespec64 Arnd Bergmann
2018-04-27 20:56 ` Radim Krčmář [this message]
2018-04-27 20:56 ` Radim Krčmář
2018-04-27 20:56   ` Radim Krčmář
2018-04-27 22:21 ` Joao Martins
2018-04-27 22:21 ` Joao Martins
2018-04-28 10:09   ` Arnd Bergmann
2018-05-02 16:44     ` Joao Martins
2018-05-02 16:44     ` Joao Martins
2018-04-28 10:09   ` Arnd Bergmann
2018-04-28  7:25 ` Jan Kiszka
2018-04-28  7:25 ` Jan Kiszka
2018-05-19 12:06 ` [tip:timers/2038] " tip-bot for Arnd Bergmann
  -- strict thread matches above, loose matches on Subject: below --
2018-04-27 20:13 [PATCH] [v3] " Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='20180427205621.GE23874__31110.9028793455$1524862527$gmane$org@flask' \
    --to=rkrcmar@redhat.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@suse.de \
    --cc=hpa@zytor.com \
    --cc=jailhouse-dev@googlegroups.com \
    --cc=jan.kiszka@siemens.com \
    --cc=jgross@suse.com \
    --cc=joao.m.martins@oracle.com \
    --cc=john.stultz@linaro.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=y2038@lists.linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.