linux.git/arch/x86/kernel/pvclock.c, branch v4.18

x86: Convert x86_platform_ops to timespec64

2018-05-19T12:03:14+00:00

The x86 platform operations are fairly isolated, so it's easy to change
them from using timespec to timespec64. It has been 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 fixing this is outside the
  scope of this change, Add a comment at least.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Boris Ostrovsky 
Acked-by: Radim Krčmář 
Acked-by: Jan Kiszka 
Cc: Juergen Gross 
Cc: jailhouse-dev@googlegroups.com
Cc: Borislav Petkov 
Cc: kvm@vger.kernel.org
Cc: y2038@lists.linaro.org
Cc: "Rafael J. Wysocki" 
Cc: xen-devel@lists.xenproject.org
Cc: John Stultz 
Cc: Andy Lutomirski 
Cc: "H. Peter Anvin" 
Cc: Paolo Bonzini 
Cc: Andy Shevchenko 
Cc: Joao Martins 
Link: https://lkml.kernel.org/r/20180427201435.3194219-1-arnd@arndb.de

x86/pvclock: add setter for pvclock_pvti_cpu0_va

2017-11-08T21:33:14+00:00

Right now there is only a pvclock_pvti_cpu0_va() which is defined
on kvmclock since:

commit dac16fba6fc5
("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")

The only user of this interface so far is kvm. This commit adds a
setter function for the pvti page and moves pvclock_pvti_cpu0_va
to pvclock, which is a more generic place to have it; and would
allow other PV clocksources to use it, such as Xen.

While moving pvclock_pvti_cpu0_va into pvclock, rename also this
function to pvclock_get_pvti_cpu0_va (including its call sites)
to be symmetric with the setter (pvclock_set_pvti_cpu0_va).

Signed-off-by: Joao Martins 
Acked-by: Andy Lutomirski 
Acked-by: Paolo Bonzini 
Acked-by: Thomas Gleixner 
Signed-off-by: Boris Ostrovsky

sched/headers: Prepare for new header dependencies before moving code to

2017-03-02T07:42:30+00:00

We are going to move softlockup APIs out of , which
will have to be picked up from other headers and a couple of .c files.

 already includes .

Include the  header in the files that are going to need it.

Acked-by: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar

clocksource: Use a plain u64 instead of cycle_t

2016-12-25T10:04:12+00:00

There is no point in having an extra type for extra confusion. u64 is
unambiguous.

Conversion was done with the following coccinelle script:

@rem@
@@
-typedef u64 cycle_t;

@fix@
typedef cycle_t;
@@
-cycle_t
+u64

Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: John Stultz

KVM: x86: introduce get_kvmclock_ns

2016-09-20T07:26:15+00:00

Introduce a function that reads the exact nanoseconds value that is
provided to the guest in kvmclock.  This crystallizes the notion of
kvmclock as a thin veneer over a stable TSC, that the guest will
(hopefully) convert with NTP.  In other words, kvmclock is *not* a
paravirtualized host-to-guest NTP.

Drop the get_kernel_ns() function, that was used both to get the base
value of the master clock and to get the current value of kvmclock.
The former use is replaced by ktime_get_boot_ns(), the latter is
the purpose of get_kernel_ns().

This also allows KVM to provide a Hyper-V time reference counter that
is synchronized with the time that is computed from the TSC page.

Reviewed-by: Roman Kagan 
Signed-off-by: Paolo Bonzini

pvclock: introduce seqcount-like API

2016-08-04T11:52:21+00:00

The version field in struct pvclock_vcpu_time_info basically implements
a seqcount.  Wrap it with the usual read_begin and read_retry functions,
and use these APIs instead of peppering the code with smp_rmb()s.
While at it, change it to the more pedantically correct virt_rmb().

With this change, __pvclock_read_cycles can be simplified noticeably.

Signed-off-by: Paolo Bonzini

pvclock: Get rid of __pvclock_read_cycles in function pvclock_read_flags

2016-06-27T13:12:15+00:00

There is a generic function __pvclock_read_cycles to be used to get both
flags and cycles. For function pvclock_read_flags, it's useless to get
cycles value. To make this function be more effective, get this variable
flags directly in function.

Signed-off-by: Minfei Huang 
Signed-off-by: Paolo Bonzini

pvclock: Add CPU barriers to get correct version value

2016-06-27T13:12:14+00:00

Protocol for the "version" fields is: hypervisor raises it (making it
uneven) before it starts updating the fields and raises it again (making
it even) when it is done.  Thus the guest can make sure the time values
it got are consistent by checking the version before and after reading
them.

Add CPU barries after getting version value just like what function
vread_pvclock does, because all of callees in this function is inline.

Fixes: 502dfeff239e8313bfbe906ca0a1a6827ac8481b
Cc: stable@vger.kernel.org
Signed-off-by: Minfei Huang 
Signed-off-by: Paolo Bonzini

x86/vdso: Remove pvclock fixmap machinery

2015-12-11T07:56:03+00:00

Signed-off-by: Andy Lutomirski 
Reviewed-by: Paolo Bonzini 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/4933029991103ae44672c82b97a20035f5c1fe4f.1449702533.git.luto@kernel.org
Signed-off-by: Ingo Molnar

x86: pvclock: Really remove the sched notifier for cross-cpu migrations

2015-04-27T13:49:30+00:00

This reverts commits 0a4e6be9ca17c54817cf814b4b5aa60478c6df27
and 80f7fdb1c7f0f9266421f823964fd1962681f6ce.

The task migration notifier was originally introduced in order to support
the pvclock vsyscall with non-synchronized TSC, but KVM only supports it
with synchronized TSC.  Hence, on KVM the race condition is only needed
due to a bad implementation on the host side, and even then it's so rare
that it's mostly theoretical.

As far as KVM is concerned it's possible to fix the host, avoiding the
additional complexity in the vDSO and the (re)introduction of the task
migration notifier.

Xen, on the other hand, hasn't yet implemented vsyscall support at
all, so we do not care about its plans for non-synchronized TSC.

Reported-by: Peter Zijlstra 
Suggested-by: Marcelo Tosatti 
Signed-off-by: Paolo Bonzini