2008-06-03 21:17:29 +07:00
|
|
|
/* paravirtual clock -- common code used by kvm/xen
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
the Free Software Foundation; either version 2 of the License, or
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program; if not, write to the Free Software
|
|
|
|
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/percpu.h>
|
2012-11-28 08:28:55 +07:00
|
|
|
#include <linux/notifier.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/gfp.h>
|
|
|
|
#include <linux/bootmem.h>
|
2017-02-09 00:51:31 +07:00
|
|
|
#include <linux/nmi.h>
|
|
|
|
|
2012-11-28 08:28:55 +07:00
|
|
|
#include <asm/fixmap.h>
|
2008-06-03 21:17:29 +07:00
|
|
|
#include <asm/pvclock.h>
|
2017-11-09 00:19:55 +07:00
|
|
|
#include <asm/vgtod.h>
|
2008-06-03 21:17:29 +07:00
|
|
|
|
2010-05-11 23:17:39 +07:00
|
|
|
static u8 valid_flags __read_mostly = 0;
|
2017-11-09 00:19:55 +07:00
|
|
|
static struct pvclock_vsyscall_time_info *pvti_cpu0_va __read_mostly;
|
2010-05-11 23:17:39 +07:00
|
|
|
|
|
|
|
void pvclock_set_flags(u8 flags)
|
|
|
|
{
|
|
|
|
valid_flags = flags;
|
|
|
|
}
|
|
|
|
|
2008-07-28 21:47:52 +07:00
|
|
|
unsigned long pvclock_tsc_khz(struct pvclock_vcpu_time_info *src)
|
|
|
|
{
|
2008-09-24 01:01:45 +07:00
|
|
|
u64 pv_tsc_khz = 1000000ULL << 32;
|
2008-07-28 21:47:52 +07:00
|
|
|
|
2008-09-24 01:01:45 +07:00
|
|
|
do_div(pv_tsc_khz, src->tsc_to_system_mul);
|
2008-07-28 21:47:52 +07:00
|
|
|
if (src->tsc_shift < 0)
|
2008-09-24 01:01:45 +07:00
|
|
|
pv_tsc_khz <<= -src->tsc_shift;
|
2008-07-28 21:47:52 +07:00
|
|
|
else
|
2008-09-24 01:01:45 +07:00
|
|
|
pv_tsc_khz >>= src->tsc_shift;
|
|
|
|
return pv_tsc_khz;
|
2008-07-28 21:47:52 +07:00
|
|
|
}
|
|
|
|
|
2013-10-12 07:39:25 +07:00
|
|
|
void pvclock_touch_watchdogs(void)
|
|
|
|
{
|
|
|
|
touch_softlockup_watchdog_sync();
|
|
|
|
clocksource_touch_watchdog();
|
|
|
|
rcu_cpu_stall_reset();
|
2013-10-12 07:39:26 +07:00
|
|
|
reset_hung_task_detector();
|
2013-10-12 07:39:25 +07:00
|
|
|
}
|
|
|
|
|
x86, paravirt: Add a global synchronization point for pvclock
In recent stress tests, it was found that pvclock-based systems
could seriously warp in smp systems. Using ingo's time-warp-test.c,
I could trigger a scenario as bad as 1.5mi warps a minute in some systems.
(to be fair, it wasn't that bad in most of them). Investigating further, I
found out that such warps were caused by the very offset-based calculation
pvclock is based on.
This happens even on some machines that report constant_tsc in its tsc flags,
specially on multi-socket ones.
Two reads of the same kernel timestamp at approx the same time, will likely
have tsc timestamped in different occasions too. This means the delta we
calculate is unpredictable at best, and can probably be smaller in a cpu
that is legitimately reading clock in a forward ocasion.
Some adjustments on the host could make this window less likely to happen,
but still, it pretty much poses as an intrinsic problem of the mechanism.
A while ago, I though about using a shared variable anyway, to hold clock
last state, but gave up due to the high contention locking was likely
to introduce, possibly rendering the thing useless on big machines. I argue,
however, that locking is not necessary.
We do a read-and-return sequence in pvclock, and between read and return,
the global value can have changed. However, it can only have changed
by means of an addition of a positive value. So if we detected that our
clock timestamp is less than the current global, we know that we need to
return a higher one, even though it is not exactly the one we compared to.
OTOH, if we detect we're greater than the current time source, we atomically
replace the value with our new readings. This do causes contention on big
boxes (but big here means *BIG*), but it seems like a good trade off, since
it provide us with a time source guaranteed to be stable wrt time warps.
After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.
Signed-off-by: Glauber Costa <glommer@redhat.com>
Acked-by: Zachary Amsden <zamsden@redhat.com>
CC: Jeremy Fitzhardinge <jeremy@goop.org>
CC: Avi Kivity <avi@redhat.com>
CC: Marcelo Tosatti <mtosatti@redhat.com>
CC: Zachary Amsden <zamsden@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-11 23:17:40 +07:00
|
|
|
static atomic64_t last_value = ATOMIC64_INIT(0);
|
|
|
|
|
2010-10-26 06:53:46 +07:00
|
|
|
void pvclock_resume(void)
|
|
|
|
{
|
|
|
|
atomic64_set(&last_value, 0);
|
|
|
|
}
|
|
|
|
|
2012-11-28 08:28:52 +07:00
|
|
|
u8 pvclock_read_flags(struct pvclock_vcpu_time_info *src)
|
|
|
|
{
|
|
|
|
unsigned version;
|
|
|
|
u8 flags;
|
|
|
|
|
|
|
|
do {
|
2016-06-09 18:06:08 +07:00
|
|
|
version = pvclock_read_begin(src);
|
2016-05-28 19:27:43 +07:00
|
|
|
flags = src->flags;
|
2016-06-09 18:06:08 +07:00
|
|
|
} while (pvclock_read_retry(src, version));
|
2012-11-28 08:28:52 +07:00
|
|
|
|
|
|
|
return flags & valid_flags;
|
|
|
|
}
|
|
|
|
|
2016-12-22 02:32:01 +07:00
|
|
|
u64 pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
|
2008-06-03 21:17:29 +07:00
|
|
|
{
|
|
|
|
unsigned version;
|
2016-12-22 02:32:01 +07:00
|
|
|
u64 ret;
|
x86, paravirt: Add a global synchronization point for pvclock
In recent stress tests, it was found that pvclock-based systems
could seriously warp in smp systems. Using ingo's time-warp-test.c,
I could trigger a scenario as bad as 1.5mi warps a minute in some systems.
(to be fair, it wasn't that bad in most of them). Investigating further, I
found out that such warps were caused by the very offset-based calculation
pvclock is based on.
This happens even on some machines that report constant_tsc in its tsc flags,
specially on multi-socket ones.
Two reads of the same kernel timestamp at approx the same time, will likely
have tsc timestamped in different occasions too. This means the delta we
calculate is unpredictable at best, and can probably be smaller in a cpu
that is legitimately reading clock in a forward ocasion.
Some adjustments on the host could make this window less likely to happen,
but still, it pretty much poses as an intrinsic problem of the mechanism.
A while ago, I though about using a shared variable anyway, to hold clock
last state, but gave up due to the high contention locking was likely
to introduce, possibly rendering the thing useless on big machines. I argue,
however, that locking is not necessary.
We do a read-and-return sequence in pvclock, and between read and return,
the global value can have changed. However, it can only have changed
by means of an addition of a positive value. So if we detected that our
clock timestamp is less than the current global, we know that we need to
return a higher one, even though it is not exactly the one we compared to.
OTOH, if we detect we're greater than the current time source, we atomically
replace the value with our new readings. This do causes contention on big
boxes (but big here means *BIG*), but it seems like a good trade off, since
it provide us with a time source guaranteed to be stable wrt time warps.
After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.
Signed-off-by: Glauber Costa <glommer@redhat.com>
Acked-by: Zachary Amsden <zamsden@redhat.com>
CC: Jeremy Fitzhardinge <jeremy@goop.org>
CC: Avi Kivity <avi@redhat.com>
CC: Marcelo Tosatti <mtosatti@redhat.com>
CC: Zachary Amsden <zamsden@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-11 23:17:40 +07:00
|
|
|
u64 last;
|
2012-11-28 08:28:50 +07:00
|
|
|
u8 flags;
|
2008-06-03 21:17:29 +07:00
|
|
|
|
|
|
|
do {
|
2016-06-09 18:06:08 +07:00
|
|
|
version = pvclock_read_begin(src);
|
2016-09-01 19:21:03 +07:00
|
|
|
ret = __pvclock_read_cycles(src, rdtsc_ordered());
|
2016-06-09 18:06:08 +07:00
|
|
|
flags = src->flags;
|
|
|
|
} while (pvclock_read_retry(src, version));
|
2008-06-03 21:17:29 +07:00
|
|
|
|
2013-10-12 07:39:25 +07:00
|
|
|
if (unlikely((flags & PVCLOCK_GUEST_STOPPED) != 0)) {
|
|
|
|
src->flags &= ~PVCLOCK_GUEST_STOPPED;
|
|
|
|
pvclock_touch_watchdogs();
|
|
|
|
}
|
|
|
|
|
2010-05-11 23:17:45 +07:00
|
|
|
if ((valid_flags & PVCLOCK_TSC_STABLE_BIT) &&
|
2012-11-28 08:28:50 +07:00
|
|
|
(flags & PVCLOCK_TSC_STABLE_BIT))
|
2010-05-11 23:17:45 +07:00
|
|
|
return ret;
|
|
|
|
|
x86, paravirt: Add a global synchronization point for pvclock
In recent stress tests, it was found that pvclock-based systems
could seriously warp in smp systems. Using ingo's time-warp-test.c,
I could trigger a scenario as bad as 1.5mi warps a minute in some systems.
(to be fair, it wasn't that bad in most of them). Investigating further, I
found out that such warps were caused by the very offset-based calculation
pvclock is based on.
This happens even on some machines that report constant_tsc in its tsc flags,
specially on multi-socket ones.
Two reads of the same kernel timestamp at approx the same time, will likely
have tsc timestamped in different occasions too. This means the delta we
calculate is unpredictable at best, and can probably be smaller in a cpu
that is legitimately reading clock in a forward ocasion.
Some adjustments on the host could make this window less likely to happen,
but still, it pretty much poses as an intrinsic problem of the mechanism.
A while ago, I though about using a shared variable anyway, to hold clock
last state, but gave up due to the high contention locking was likely
to introduce, possibly rendering the thing useless on big machines. I argue,
however, that locking is not necessary.
We do a read-and-return sequence in pvclock, and between read and return,
the global value can have changed. However, it can only have changed
by means of an addition of a positive value. So if we detected that our
clock timestamp is less than the current global, we know that we need to
return a higher one, even though it is not exactly the one we compared to.
OTOH, if we detect we're greater than the current time source, we atomically
replace the value with our new readings. This do causes contention on big
boxes (but big here means *BIG*), but it seems like a good trade off, since
it provide us with a time source guaranteed to be stable wrt time warps.
After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.
Signed-off-by: Glauber Costa <glommer@redhat.com>
Acked-by: Zachary Amsden <zamsden@redhat.com>
CC: Jeremy Fitzhardinge <jeremy@goop.org>
CC: Avi Kivity <avi@redhat.com>
CC: Marcelo Tosatti <mtosatti@redhat.com>
CC: Zachary Amsden <zamsden@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-11 23:17:40 +07:00
|
|
|
/*
|
|
|
|
* Assumption here is that last_value, a global accumulator, always goes
|
|
|
|
* forward. If we are less than that, we should not be much smaller.
|
|
|
|
* We assume there is an error marging we're inside, and then the correction
|
|
|
|
* does not sacrifice accuracy.
|
|
|
|
*
|
|
|
|
* For reads: global may have changed between test and return,
|
|
|
|
* but this means someone else updated poked the clock at a later time.
|
|
|
|
* We just need to make sure we are not seeing a backwards event.
|
|
|
|
*
|
|
|
|
* For updates: last_value = ret is not enough, since two vcpus could be
|
|
|
|
* updating at the same time, and one of them could be slightly behind,
|
|
|
|
* making the assumption that last_value always go forward fail to hold.
|
|
|
|
*/
|
|
|
|
last = atomic64_read(&last_value);
|
|
|
|
do {
|
|
|
|
if (ret < last)
|
|
|
|
return last;
|
|
|
|
last = atomic64_cmpxchg(&last_value, last, ret);
|
|
|
|
} while (unlikely(last != ret));
|
|
|
|
|
2008-06-03 21:17:29 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
void pvclock_read_wallclock(struct pvclock_wall_clock *wall_clock,
|
|
|
|
struct pvclock_vcpu_time_info *vcpu_time,
|
|
|
|
struct timespec *ts)
|
|
|
|
{
|
|
|
|
u32 version;
|
|
|
|
u64 delta;
|
|
|
|
struct timespec now;
|
|
|
|
|
|
|
|
/* get wallclock at system boot */
|
|
|
|
do {
|
|
|
|
version = wall_clock->version;
|
|
|
|
rmb(); /* fetch version before time */
|
|
|
|
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;
|
|
|
|
|
|
|
|
now.tv_nsec = do_div(delta, NSEC_PER_SEC);
|
|
|
|
now.tv_sec = delta;
|
|
|
|
|
|
|
|
set_normalized_timespec(ts, now.tv_sec, now.tv_nsec);
|
|
|
|
}
|
2017-11-09 00:19:55 +07:00
|
|
|
|
|
|
|
void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti)
|
|
|
|
{
|
|
|
|
WARN_ON(vclock_was_used(VCLOCK_PVCLOCK));
|
|
|
|
pvti_cpu0_va = pvti;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct pvclock_vsyscall_time_info *pvclock_get_pvti_cpu0_va(void)
|
|
|
|
{
|
|
|
|
return pvti_cpu0_va;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pvclock_get_pvti_cpu0_va);
|