diff mbox series

[RESEND] KVM: x86: use timespec64 for KVM_HC_CLOCK_PAIRING

Message ID 20180423080512.1614520-1-arnd@arndb.de
State Accepted
Commit 899a31f509ee1c6f7008c3265d1f625bfcb23311
Headers show
Series [RESEND] KVM: x86: use timespec64 for KVM_HC_CLOCK_PAIRING | expand

Commit Message

Arnd Bergmann April 23, 2018, 8:04 a.m. UTC
The hypercall was added using a struct timespec based implementation,
but we should not use timespec in new code.

This changes it to timespec64. There is no functional change
here since the implementation is only used in 64-bit kernels
that use the same definition for timespec and timespec64.

Fixes: 55dd00a73a51 ("KVM: x86: add KVM_HC_CLOCK_PAIRING hypercall")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

---
I originally sent this in October, but got no reply. The patch
is still required for the overall cleanup of 'timespec' uses
in the kernel, please apply.
---
 arch/x86/kvm/x86.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.9.0

Comments

Radim Krčmář April 27, 2018, 7:32 p.m. UTC | #1
2018-04-23 10:04+0200, Arnd Bergmann:
> The hypercall was added using a struct timespec based implementation,

> but we should not use timespec in new code.

> 

> This changes it to timespec64. There is no functional change

> here since the implementation is only used in 64-bit kernels

> that use the same definition for timespec and timespec64.

> 

> Fixes: 55dd00a73a51 ("KVM: x86: add KVM_HC_CLOCK_PAIRING hypercall")


(Removed the "Fixes:" tag as it doesn't really change behavior.)

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

> ---

> I originally sent this in October, but got no reply. The patch

> is still required for the overall cleanup of 'timespec' uses

> in the kernel, please apply.


Queued now, thanks!

Anything we need to do for the x86_platform_ops switch?
Arnd Bergmann April 27, 2018, 7:45 p.m. UTC | #2
On Fri, Apr 27, 2018 at 9:32 PM, Radim Krčmář <rkrcmar@redhat.com> wrote:
> 2018-04-23 10:04+0200, Arnd Bergmann:

>> The hypercall was added using a struct timespec based implementation,

>> but we should not use timespec in new code.

>>

>> This changes it to timespec64. There is no functional change

>> here since the implementation is only used in 64-bit kernels

>> that use the same definition for timespec and timespec64.

>>

>> Fixes: 55dd00a73a51 ("KVM: x86: add KVM_HC_CLOCK_PAIRING hypercall")

>

> (Removed the "Fixes:" tag as it doesn't really change behavior.)

>

>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

>> ---

>> I originally sent this in October, but got no reply. The patch

>> is still required for the overall cleanup of 'timespec' uses

>> in the kernel, please apply.

>

> Queued now, thanks!

>

> Anything we need to do for the x86_platform_ops switch?


I think it's on me to resend what I have. That patch is one of the few
remaining ones in my backlog for y2038 after having sent out
some 50 other patches (some new, some old).

It has been in my testing tree since October though and not shown
any regressions for a while (I had to do one modification after
Jailhouse got merged), so I'll just send it out now.

       Arnd
Arnd Bergmann April 27, 2018, 7:58 p.m. UTC | #3
On Fri, Apr 27, 2018 at 9:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Apr 27, 2018 at 9:32 PM, Radim Krčmář <rkrcmar@redhat.com> wrote:

>> 2018-04-23 10:04+0200, Arnd Bergmann:

>>> The hypercall was added using a struct timespec based implementation,

>>> but we should not use timespec in new code.

>>>

>>> This changes it to timespec64. There is no functional change

>>> here since the implementation is only used in 64-bit kernels

>>> that use the same definition for timespec and timespec64.

>>>

>>> Fixes: 55dd00a73a51 ("KVM: x86: add KVM_HC_CLOCK_PAIRING hypercall")

>>

>> (Removed the "Fixes:" tag as it doesn't really change behavior.)

>>

>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

>>> ---

>>> I originally sent this in October, but got no reply. The patch

>>> is still required for the overall cleanup of 'timespec' uses

>>> in the kernel, please apply.

>>

>> Queued now, thanks!

>>

>> Anything we need to do for the x86_platform_ops switch?

>

> I think it's on me to resend what I have. That patch is one of the few

> remaining ones in my backlog for y2038 after having sent out

> some 50 other patches (some new, some old).

>

> It has been in my testing tree since October though and not shown

> any regressions for a while (I had to do one modification after

> Jailhouse got merged), so I'll just send it out now.


I remember the problem now, that patch relied on another
one that turned out to be too ugly:
https://patchwork.kernel.org/patch/10016923/

I still had that as part of my own test builds, as the one that
we do want fails without it. However, one other patch I
sent today ("timekeeping: Remove timespec64 hack")
should provide a better path and let me completely
avoid that hack. I'll give that a try now and send the
modified x86_platform_ops patch.

       Arnd
diff mbox series

Patch

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index b2ff74b12ec4..961ee64cb137 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1755,7 +1755,7 @@  static int do_monotonic_boot(s64 *t, u64 *tsc_timestamp)
 	return mode;
 }
 
-static int do_realtime(struct timespec *ts, u64 *tsc_timestamp)
+static int do_realtime(struct timespec64 *ts, u64 *tsc_timestamp)
 {
 	struct pvclock_gtod_data *gtod = &pvclock_gtod_data;
 	unsigned long seq;
@@ -1788,7 +1788,7 @@  static bool kvm_get_time_and_clockread(s64 *kernel_ns, u64 *tsc_timestamp)
 }
 
 /* returns true if host is using TSC based clocksource */
-static bool kvm_get_walltime_and_clockread(struct timespec *ts,
+static bool kvm_get_walltime_and_clockread(struct timespec64 *ts,
 					   u64 *tsc_timestamp)
 {
 	/* checked again under seqlock below */
@@ -6610,7 +6610,7 @@  static int kvm_pv_clock_pairing(struct kvm_vcpu *vcpu, gpa_t paddr,
 			        unsigned long clock_type)
 {
 	struct kvm_clock_pairing clock_pairing;
-	struct timespec ts;
+	struct timespec64 ts;
 	u64 cycle;
 	int ret;