// SPDX-License-Identifier: GPL-2.0 /* * Xen time implementation. * * This is implemented in terms of a clocksource driver which uses * the hypervisor clock as a nanosecond timebase, and a clockevent * driver which uses the hypervisor's timer mechanism. * * Jeremy Fitzhardinge <jeremy@xensource.com>, XenSource Inc, 2007
*/ #include <linux/kernel.h> #include <linux/interrupt.h> #include <linux/clocksource.h> #include <linux/clockchips.h> #include <linux/gfp.h> #include <linux/slab.h> #include <linux/pvclock_gtod.h> #include <linux/timekeeper_internal.h>
/* * We only take the expensive HV call when the clock was set * or when the 11 minutes RTC synchronization time elapsed.
*/ if (!was_set && timespec64_compare(&now, &next_sync) < 0) return NOTIFY_OK;
The old timer_op one works with all released versions of Xen prior to version 3.0.4. This version of the hypervisor provides a single-shot timer with nanosecond resolution. However, sharing the same event channel is a 100Hz tick which is delivered while the vcpu is running. We don't care about or use this tick, but it will cause the core time code to think the timer fired too soon, and will end up resetting it each time. It could be filtered, but doing so has complications when the ktime clocksource is not yet the xen clocksource (ie, at boot time).
The new vcpu_op-based timer interface allows the tick timer period to be changed or turned off. The tick timer is not useful as a periodic timer because events are only delivered to running vcpus. The one-shot timer can report when a timeout is in the past, so set_next_event is capable of returning -ETIME when appropriate. This interface is used when available.
*/
/* Get a hypervisor absolute time. In theory we could maintain an offset between the kernel's time and the hypervisor's time, and apply that to a kernel's absolute timeout. Unfortunately the hypervisor and kernel times can drift even if the kernel is using the Xen clocksource, because ntp can warp the kernel's clocksource.
*/ static s64 get_abs_timeout(unsignedlong delta)
{ return xen_clocksource_read() + delta;
}
if (HYPERVISOR_set_timer_op(get_abs_timeout(delta)) < 0)
BUG();
/* We may have missed the deadline, but there's no real way of knowing for sure. If the event was in the past, then we'll
get an immediate interrupt. */
ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t); if (ret != 0)
pr_notice("Cannot save secondary vcpu_time_info (err %d)",
ret); else
clear_page(xen_clock);
}
void xen_restore_time_memory_area(void)
{ struct vcpu_register_time_memory_area t; int ret;
if (!xen_clock) goto out;
t.addr.v = &xen_clock->pvti;
ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t);
/* * We don't disable VDSO_CLOCKMODE_PVCLOCK entirely if it fails to * register the secondary time info with Xen or if we migrated to a * host without the necessary flags. On both of these cases what * happens is either process seeing a zeroed out pvti or seeing no * PVCLOCK_TSC_STABLE_BIT bit set. Userspace checks the latter and * if 0, it discards the data in pvti and fallbacks to a system * call for a reliable timestamp.
*/ if (ret != 0)
pr_notice("Cannot restore secondary vcpu_time_info (err %d)",
ret);
out: /* Need pvclock_resume() before using xen_clocksource_read(). */
pvclock_resume();
xen_sched_clock_offset = xen_clocksource_read() - xen_clock_value_saved;
}
ti = (struct pvclock_vsyscall_time_info *)get_zeroed_page(GFP_KERNEL); if (!ti) return;
t.addr.v = &ti->pvti;
ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t); if (ret) {
pr_notice("xen: VDSO_CLOCKMODE_PVCLOCK not supported (err %d)\n", ret);
free_page((unsignedlong)ti); return;
}
/* * If primary time info had this bit set, secondary should too since * it's the same data on both just different memory regions. But we * still check it in case hypervisor is buggy.
*/ if (!(ti->pvti.flags & PVCLOCK_TSC_STABLE_BIT)) {
t.addr.v = NULL;
ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area,
0, &t); if (!ret)
free_page((unsignedlong)ti);
pr_notice("xen: VDSO_CLOCKMODE_PVCLOCK not supported (tsc unstable)\n"); return;
}
/* * Check if it is possible to safely use the tsc as a clocksource. This is * only true if the hypervisor notifies the guest that its tsc is invariant, * the tsc is stable, and the tsc instruction will never be emulated.
*/ staticint __init xen_tsc_safe_clocksource(void)
{
u32 eax, ebx, ecx, edx;
if (!(boot_cpu_has(X86_FEATURE_CONSTANT_TSC))) return 0;
if (!(boot_cpu_has(X86_FEATURE_NONSTOP_TSC))) return 0;
staticvoid __init xen_time_init(void)
{ struct pvclock_vcpu_time_info *pvti; int cpu = smp_processor_id(); struct timespec64 tp;
/* * As Dom0 is never moved, no penalty on using TSC there. * * If it is possible for the guest to determine that the tsc is a safe * clocksource, then set xen_clocksource rating below that of the tsc * so that the system prefers tsc instead.
*/ if (xen_initial_domain())
xen_clocksource.rating = 275; elseif (xen_tsc_safe_clocksource())
xen_clocksource.rating = 299;
if (HYPERVISOR_vcpu_op(VCPUOP_stop_periodic_timer, xen_vcpu_nr(cpu),
NULL) == 0) { /* Successfully turned off 100Hz tick, so we have the
vcpuop-based timer interface */
printk(KERN_DEBUG "Xen: using vcpuop timer interface\n");
xen_clockevent = &xen_vcpuop_clockevent;
}
/* Set initial system time with full resolution */
xen_read_wallclock(&tp);
do_settimeofday64(&tp);
setup_force_cpu_cap(X86_FEATURE_TSC);
/* * We check ahead on the primary time info if this * bit is supported hence speeding up Xen clocksource.
*/
pvti = &__this_cpu_read(xen_vcpu)->time; if (pvti->flags & PVCLOCK_TSC_STABLE_BIT) {
pvclock_set_flags(PVCLOCK_TSC_STABLE_BIT);
xen_setup_vsyscall_time_info();
}
/* Dom0 uses the native method to set the hardware RTC. */ if (!xen_initial_domain())
x86_platform.set_wallclock = xen_set_wallclock;
}
#ifdef CONFIG_XEN_PVHVM staticvoid xen_hvm_setup_cpu_clockevents(void)
{ int cpu = smp_processor_id();
xen_setup_runstate_info(cpu); /* * xen_setup_timer(cpu) - snprintf is bad in atomic context. Hence * doing it xen_hvm_cpu_notify (which gets called by smp_init during * early bootup and also during CPU hotplug events).
*/
xen_setup_cpu_clockevents();
}
/* * vector callback is needed otherwise we cannot receive interrupts * on cpu > 0 and at this point we don't know how many cpus are * available.
*/ if (!xen_have_vector_callback) return;
if (!xen_feature(XENFEAT_hvm_safe_pvclock)) {
pr_info_once("Xen doesn't support pvclock on HVM, disable pv timer"); return;
}
/* * Only MAX_VIRT_CPUS 'vcpu_info' are embedded inside 'shared_info'. * The __this_cpu_read(xen_vcpu) is still NULL when Xen HVM guest * boots on vcpu >= MAX_VIRT_CPUS (e.g., kexec), To access * __this_cpu_read(xen_vcpu) via xen_clocksource_read() will panic. * * The xen_hvm_init_time_ops() should be called again later after * __this_cpu_read(xen_vcpu) is available.
*/ if (!__this_cpu_read(xen_vcpu)) {
pr_info("Delay xen_init_time_common() as kernel is running on vcpu=%d\n",
xen_vcpu_nr(0)); return;
}
Die Informationen auf dieser Webseite wurden
nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit,
noch Qualität der bereit gestellten Informationen zugesichert.
Bemerkung:
Die farbliche Syntaxdarstellung und die Messung sind noch experimentell.