| 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 |
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?
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
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 --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;
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