2019-07-01 07:25:56 +03:00
// SPDX-License-Identifier: GPL-2.0
/*
* Clocksource driver for the synthetic counter and timers
* provided by the Hyper - V hypervisor to guest VMs , as described
* in the Hyper - V Top Level Functional Spec ( TLFS ) . This driver
* is instruction set architecture independent .
*
* Copyright ( C ) 2019 , Microsoft , Inc .
*
* Author : Michael Kelley < mikelley @ microsoft . com >
*/
# include <linux/percpu.h>
# include <linux/cpumask.h>
# include <linux/clockchips.h>
2019-07-01 07:26:06 +03:00
# include <linux/clocksource.h>
# include <linux/sched_clock.h>
2019-07-01 07:25:56 +03:00
# include <linux/mm.h>
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
# include <linux/cpuhotplug.h>
2019-07-01 07:25:56 +03:00
# include <clocksource/hyperv_timer.h>
# include <asm/hyperv-tlfs.h>
# include <asm/mshyperv.h>
static struct clock_event_device __percpu * hv_clock_event ;
2019-08-14 15:32:16 +03:00
static u64 hv_sched_clock_offset __ro_after_init ;
2019-07-01 07:25:56 +03:00
/*
* If false , we ' re using the old mechanism for stimer0 interrupts
* where it sends a VMbus message when it expires . The old
* mechanism is used when running on older versions of Hyper - V
* that don ' t support Direct Mode . While Hyper - V provides
* four stimer ' s per CPU , Linux uses only stimer0 .
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
*
* Because Direct Mode does not require processing a VMbus
* message , stimer interrupts can be enabled earlier in the
* process of booting a CPU , and consistent with when timer
* interrupts are enabled for other clocksource drivers .
* However , for legacy versions of Hyper - V when Direct Mode
* is not enabled , setting up stimer interrupts must be
* delayed until VMbus is initialized and can process the
* interrupt message .
2019-07-01 07:25:56 +03:00
*/
static bool direct_mode_enabled ;
static int stimer0_irq ;
static int stimer0_vector ;
static int stimer0_message_sint ;
/*
* ISR for when stimer0 is operating in Direct Mode . Direct Mode
* does not use VMbus or any VMbus messages , so process here and not
* in the VMbus driver code .
*/
void hv_stimer0_isr ( void )
{
struct clock_event_device * ce ;
ce = this_cpu_ptr ( hv_clock_event ) ;
ce - > event_handler ( ce ) ;
}
EXPORT_SYMBOL_GPL ( hv_stimer0_isr ) ;
static int hv_ce_set_next_event ( unsigned long delta ,
struct clock_event_device * evt )
{
u64 current_tick ;
2020-01-09 19:06:49 +03:00
current_tick = hv_read_reference_counter ( ) ;
2019-07-01 07:25:56 +03:00
current_tick + = delta ;
hv_init_timer ( 0 , current_tick ) ;
return 0 ;
}
static int hv_ce_shutdown ( struct clock_event_device * evt )
{
hv_init_timer ( 0 , 0 ) ;
hv_init_timer_config ( 0 , 0 ) ;
if ( direct_mode_enabled )
hv_disable_stimer0_percpu_irq ( stimer0_irq ) ;
return 0 ;
}
static int hv_ce_set_oneshot ( struct clock_event_device * evt )
{
union hv_stimer_config timer_cfg ;
timer_cfg . as_uint64 = 0 ;
timer_cfg . enable = 1 ;
timer_cfg . auto_enable = 1 ;
if ( direct_mode_enabled ) {
/*
* When it expires , the timer will directly interrupt
* on the specified hardware vector / IRQ .
*/
timer_cfg . direct_mode = 1 ;
timer_cfg . apic_vector = stimer0_vector ;
hv_enable_stimer0_percpu_irq ( stimer0_irq ) ;
} else {
/*
* When it expires , the timer will generate a VMbus message ,
* to be handled by the normal VMbus interrupt handler .
*/
timer_cfg . direct_mode = 0 ;
timer_cfg . sintx = stimer0_message_sint ;
}
hv_init_timer_config ( 0 , timer_cfg . as_uint64 ) ;
return 0 ;
}
/*
* hv_stimer_init - Per - cpu initialization of the clockevent
*/
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
static int hv_stimer_init ( unsigned int cpu )
2019-07-01 07:25:56 +03:00
{
struct clock_event_device * ce ;
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
if ( ! hv_clock_event )
return 0 ;
2019-07-01 07:25:56 +03:00
ce = per_cpu_ptr ( hv_clock_event , cpu ) ;
ce - > name = " Hyper-V clockevent " ;
ce - > features = CLOCK_EVT_FEAT_ONESHOT ;
ce - > cpumask = cpumask_of ( cpu ) ;
ce - > rating = 1000 ;
ce - > set_state_shutdown = hv_ce_shutdown ;
ce - > set_state_oneshot = hv_ce_set_oneshot ;
ce - > set_next_event = hv_ce_set_next_event ;
clockevents_config_and_register ( ce ,
HV_CLOCK_HZ ,
HV_MIN_DELTA_TICKS ,
HV_MAX_MAX_DELTA_TICKS ) ;
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
return 0 ;
2019-07-01 07:25:56 +03:00
}
/*
* hv_stimer_cleanup - Per - cpu cleanup of the clockevent
*/
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
int hv_stimer_cleanup ( unsigned int cpu )
2019-07-01 07:25:56 +03:00
{
struct clock_event_device * ce ;
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
if ( ! hv_clock_event )
return 0 ;
/*
* In the legacy case where Direct Mode is not enabled
* ( which can only be on x86 / 64 ) , stimer cleanup happens
* relatively early in the CPU offlining process . We
* must unbind the stimer - based clockevent device so
* that the LAPIC timer can take over until clockevents
* are no longer needed in the offlining process . Note
* that clockevents_unbind_device ( ) eventually calls
* hv_ce_shutdown ( ) .
*
* The unbind should not be done when Direct Mode is
* enabled because we may be on an architecture where
* there are no other clockevent devices to fallback to .
*/
ce = per_cpu_ptr ( hv_clock_event , cpu ) ;
if ( direct_mode_enabled )
2019-07-01 07:25:56 +03:00
hv_ce_shutdown ( ce ) ;
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
else
clockevents_unbind_device ( ce , cpu ) ;
return 0 ;
2019-07-01 07:25:56 +03:00
}
EXPORT_SYMBOL_GPL ( hv_stimer_cleanup ) ;
/* hv_stimer_alloc - Global initialization of the clockevent and stimer0 */
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
int hv_stimer_alloc ( void )
2019-07-01 07:25:56 +03:00
{
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
int ret = 0 ;
/*
* Synthetic timers are always available except on old versions of
* Hyper - V on x86 . In that case , return as error as Linux will use a
* clockevent based on emulated LAPIC timer hardware .
*/
if ( ! ( ms_hyperv . features & HV_MSR_SYNTIMER_AVAILABLE ) )
return - EINVAL ;
2019-07-01 07:25:56 +03:00
hv_clock_event = alloc_percpu ( struct clock_event_device ) ;
if ( ! hv_clock_event )
return - ENOMEM ;
direct_mode_enabled = ms_hyperv . misc_features &
HV_STIMER_DIRECT_MODE_AVAILABLE ;
if ( direct_mode_enabled ) {
ret = hv_setup_stimer0_irq ( & stimer0_irq , & stimer0_vector ,
hv_stimer0_isr ) ;
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
if ( ret )
goto free_percpu ;
/*
* Since we are in Direct Mode , stimer initialization
* can be done now with a CPUHP value in the same range
* as other clockevent devices .
*/
ret = cpuhp_setup_state ( CPUHP_AP_HYPERV_TIMER_STARTING ,
" clockevents/hyperv/stimer:starting " ,
hv_stimer_init , hv_stimer_cleanup ) ;
if ( ret < 0 )
goto free_stimer0_irq ;
2019-07-01 07:25:56 +03:00
}
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
return ret ;
2019-07-01 07:25:56 +03:00
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
free_stimer0_irq :
hv_remove_stimer0_irq ( stimer0_irq ) ;
stimer0_irq = 0 ;
free_percpu :
free_percpu ( hv_clock_event ) ;
hv_clock_event = NULL ;
return ret ;
2019-07-01 07:25:56 +03:00
}
EXPORT_SYMBOL_GPL ( hv_stimer_alloc ) ;
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
/*
* hv_stimer_legacy_init - - Called from the VMbus driver to handle
* the case when Direct Mode is not enabled , and the stimer
* must be initialized late in the CPU onlining process .
*
*/
void hv_stimer_legacy_init ( unsigned int cpu , int sint )
{
if ( direct_mode_enabled )
return ;
/*
* This function gets called by each vCPU , so setting the
* global stimer_message_sint value each time is conceptually
* not ideal , but the value passed in is always the same and
* it avoids introducing yet another interface into this
* clocksource driver just to set the sint in the legacy case .
*/
stimer0_message_sint = sint ;
( void ) hv_stimer_init ( cpu ) ;
}
EXPORT_SYMBOL_GPL ( hv_stimer_legacy_init ) ;
/*
* hv_stimer_legacy_cleanup - - Called from the VMbus driver to
* handle the case when Direct Mode is not enabled , and the
* stimer must be cleaned up early in the CPU offlining
* process .
*/
void hv_stimer_legacy_cleanup ( unsigned int cpu )
{
if ( direct_mode_enabled )
return ;
( void ) hv_stimer_cleanup ( cpu ) ;
}
EXPORT_SYMBOL_GPL ( hv_stimer_legacy_cleanup ) ;
2019-07-01 07:25:56 +03:00
/* hv_stimer_free - Free global resources allocated by hv_stimer_alloc() */
void hv_stimer_free ( void )
{
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
if ( ! hv_clock_event )
return ;
if ( direct_mode_enabled ) {
cpuhp_remove_state ( CPUHP_AP_HYPERV_TIMER_STARTING ) ;
2019-07-01 07:25:56 +03:00
hv_remove_stimer0_irq ( stimer0_irq ) ;
stimer0_irq = 0 ;
}
free_percpu ( hv_clock_event ) ;
hv_clock_event = NULL ;
}
EXPORT_SYMBOL_GPL ( hv_stimer_free ) ;
/*
* Do a global cleanup of clockevents for the cases of kexec and
* vmbus exit
*/
void hv_stimer_global_cleanup ( void )
{
int cpu ;
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
/*
* hv_stime_legacy_cleanup ( ) will stop the stimer if Direct
* Mode is not enabled , and fallback to the LAPIC timer .
*/
for_each_present_cpu ( cpu ) {
hv_stimer_legacy_cleanup ( cpu ) ;
2019-07-01 07:25:56 +03:00
}
x86/hyperv: Initialize clockevents earlier in CPU onlining
Hyper-V has historically initialized stimer-based clockevents late in the
process of onlining a CPU because clockevents depend on stimer
interrupts. In the original Hyper-V design, stimer interrupts generate a
VMbus message, so the VMbus machinery must be running first, and VMbus
can't be initialized until relatively late. On x86/64, LAPIC timer based
clockevents are used during early initialization before VMbus and
stimer-based clockevents are ready, and again during CPU offlining after
the stimer clockevents have been shut down.
Unfortunately, this design creates problems when offlining CPUs for
hibernation or other purposes. stimer-based clockevents are shut down
relatively early in the offlining process, so clockevents_unbind_device()
must be used to fallback to the LAPIC-based clockevents for the remainder
of the offlining process. Furthermore, the late initialization and early
shutdown of stimer-based clockevents doesn't work well on ARM64 since there
is no other timer like the LAPIC to fallback to. So CPU onlining and
offlining doesn't work properly.
Fix this by recognizing that stimer Direct Mode is the normal path for
newer versions of Hyper-V on x86/64, and the only path on other
architectures. With stimer Direct Mode, stimer interrupts don't require any
VMbus machinery. stimer clockevents can be initialized and shut down
consistent with how it is done for other clockevent devices. While the old
VMbus-based stimer interrupts must still be supported for backward
compatibility on x86, that mode of operation can be treated as legacy.
So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
that new state when in Direct Mode. Update the Hyper-V clocksource driver
to allocate and initialize stimer clockevents earlier during boot. Update
Hyper-V initialization and the VMbus driver to use this new design. As a
result, the LAPIC timer is no longer used during boot or CPU
onlining/offlining and clockevents_unbind_device() is not called. But
retain the old design as a legacy implementation for older versions of
Hyper-V that don't support Direct Mode.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
2019-11-13 04:11:49 +03:00
/*
* If Direct Mode is enabled , the cpuhp teardown callback
* ( hv_stimer_cleanup ) will be run on all CPUs to stop the
* stimers .
*/
2019-07-01 07:25:56 +03:00
hv_stimer_free ( ) ;
}
EXPORT_SYMBOL_GPL ( hv_stimer_global_cleanup ) ;
2019-07-01 07:26:06 +03:00
/*
* Code and definitions for the Hyper - V clocksources . Two
* clocksources are defined : one that reads the Hyper - V defined MSR , and
* the other that uses the TSC reference page feature as defined in the
* TLFS . The MSR version is for compatibility with old versions of
* Hyper - V and 32 - bit x86 . The TSC reference page version is preferred .
2020-01-09 19:06:50 +03:00
*
* The Hyper - V clocksource ratings of 250 are chosen to be below the
* TSC clocksource rating of 300. In configurations where Hyper - V offers
* an InvariantTSC , the TSC is not marked " unstable " , so the TSC clocksource
* is available and preferred . With the higher rating , it will be the
* default . On older hardware and Hyper - V versions , the TSC is marked
* " unstable " , so no TSC clocksource is created and the selected Hyper - V
* clocksource will be the default .
2019-07-01 07:26:06 +03:00
*/
2020-01-09 19:06:49 +03:00
u64 ( * hv_read_reference_counter ) ( void ) ;
EXPORT_SYMBOL_GPL ( hv_read_reference_counter ) ;
2019-07-01 07:26:06 +03:00
clocksource/drivers/hyper-v: Reserve PAGE_SIZE space for tsc page
Currently, the reserved size for a tsc page is 4K, which is enough for
communicating with hypervisor. However, in the case where we want to
export the tsc page to userspace (e.g. for vDSO to read the
clocksource), the tsc page should be at least PAGE_SIZE, otherwise, when
PAGE_SIZE is larger than 4K, extra kernel data will be mapped into
userspace, which means leaking kernel information.
Therefore reserve PAGE_SIZE space for tsc_pg as a preparation for the
vDSO support of ARM64 in the future. Also, while at it, replace all
reference to tsc_pg with hv_get_tsc_page() since it should be the only
interface to access tsc page.
Signed-off-by: Boqun Feng (Microsoft) <boqun.feng@gmail.com>
Cc: linux-hyperv@vger.kernel.org
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20191126021723.4710-1-boqun.feng@gmail.com
2019-11-26 05:17:20 +03:00
static union {
struct ms_hyperv_tsc_page page ;
u8 reserved [ PAGE_SIZE ] ;
} tsc_pg __aligned ( PAGE_SIZE ) ;
2019-07-01 07:26:06 +03:00
struct ms_hyperv_tsc_page * hv_get_tsc_page ( void )
{
clocksource/drivers/hyper-v: Reserve PAGE_SIZE space for tsc page
Currently, the reserved size for a tsc page is 4K, which is enough for
communicating with hypervisor. However, in the case where we want to
export the tsc page to userspace (e.g. for vDSO to read the
clocksource), the tsc page should be at least PAGE_SIZE, otherwise, when
PAGE_SIZE is larger than 4K, extra kernel data will be mapped into
userspace, which means leaking kernel information.
Therefore reserve PAGE_SIZE space for tsc_pg as a preparation for the
vDSO support of ARM64 in the future. Also, while at it, replace all
reference to tsc_pg with hv_get_tsc_page() since it should be the only
interface to access tsc page.
Signed-off-by: Boqun Feng (Microsoft) <boqun.feng@gmail.com>
Cc: linux-hyperv@vger.kernel.org
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20191126021723.4710-1-boqun.feng@gmail.com
2019-11-26 05:17:20 +03:00
return & tsc_pg . page ;
2019-07-01 07:26:06 +03:00
}
EXPORT_SYMBOL_GPL ( hv_get_tsc_page ) ;
2020-01-09 19:06:49 +03:00
static u64 notrace read_hv_clock_tsc ( void )
2019-07-01 07:26:06 +03:00
{
clocksource/drivers/hyper-v: Reserve PAGE_SIZE space for tsc page
Currently, the reserved size for a tsc page is 4K, which is enough for
communicating with hypervisor. However, in the case where we want to
export the tsc page to userspace (e.g. for vDSO to read the
clocksource), the tsc page should be at least PAGE_SIZE, otherwise, when
PAGE_SIZE is larger than 4K, extra kernel data will be mapped into
userspace, which means leaking kernel information.
Therefore reserve PAGE_SIZE space for tsc_pg as a preparation for the
vDSO support of ARM64 in the future. Also, while at it, replace all
reference to tsc_pg with hv_get_tsc_page() since it should be the only
interface to access tsc page.
Signed-off-by: Boqun Feng (Microsoft) <boqun.feng@gmail.com>
Cc: linux-hyperv@vger.kernel.org
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20191126021723.4710-1-boqun.feng@gmail.com
2019-11-26 05:17:20 +03:00
u64 current_tick = hv_read_tsc_page ( hv_get_tsc_page ( ) ) ;
2019-07-01 07:26:06 +03:00
if ( current_tick = = U64_MAX )
hv_get_time_ref_count ( current_tick ) ;
return current_tick ;
}
2020-01-09 19:06:49 +03:00
static u64 notrace read_hv_clock_tsc_cs ( struct clocksource * arg )
{
return read_hv_clock_tsc ( ) ;
}
2020-09-24 18:11:17 +03:00
static u64 notrace read_hv_sched_clock_tsc ( void )
2019-07-01 07:26:06 +03:00
{
2020-03-27 05:11:59 +03:00
return ( read_hv_clock_tsc ( ) - hv_sched_clock_offset ) *
( NSEC_PER_SEC / HV_CLOCK_HZ ) ;
2019-07-01 07:26:06 +03:00
}
2019-11-20 10:12:26 +03:00
static void suspend_hv_clock_tsc ( struct clocksource * arg )
{
u64 tsc_msr ;
/* Disable the TSC page */
hv_get_reference_tsc ( tsc_msr ) ;
tsc_msr & = ~ BIT_ULL ( 0 ) ;
hv_set_reference_tsc ( tsc_msr ) ;
}
static void resume_hv_clock_tsc ( struct clocksource * arg )
{
phys_addr_t phys_addr = virt_to_phys ( & tsc_pg ) ;
u64 tsc_msr ;
/* Re-enable the TSC page */
hv_get_reference_tsc ( tsc_msr ) ;
tsc_msr & = GENMASK_ULL ( 11 , 0 ) ;
tsc_msr | = BIT_ULL ( 0 ) | ( u64 ) phys_addr ;
hv_set_reference_tsc ( tsc_msr ) ;
}
2020-02-07 15:38:54 +03:00
static int hv_cs_enable ( struct clocksource * cs )
{
hv_enable_vdso_clocksource ( ) ;
return 0 ;
}
2019-07-01 07:26:06 +03:00
static struct clocksource hyperv_cs_tsc = {
. name = " hyperv_clocksource_tsc_page " ,
2020-01-09 19:06:50 +03:00
. rating = 250 ,
2020-01-09 19:06:49 +03:00
. read = read_hv_clock_tsc_cs ,
2019-07-01 07:26:06 +03:00
. mask = CLOCKSOURCE_MASK ( 64 ) ,
. flags = CLOCK_SOURCE_IS_CONTINUOUS ,
2019-11-20 10:12:26 +03:00
. suspend = suspend_hv_clock_tsc ,
. resume = resume_hv_clock_tsc ,
2020-02-07 15:38:54 +03:00
. enable = hv_cs_enable ,
2019-07-01 07:26:06 +03:00
} ;
2020-01-09 19:06:49 +03:00
static u64 notrace read_hv_clock_msr ( void )
2019-07-01 07:26:06 +03:00
{
u64 current_tick ;
/*
* Read the partition counter to get the current tick count . This count
* is set to 0 when the partition is created and is incremented in
* 100 nanosecond units .
*/
hv_get_time_ref_count ( current_tick ) ;
return current_tick ;
}
2020-01-09 19:06:49 +03:00
static u64 notrace read_hv_clock_msr_cs ( struct clocksource * arg )
{
return read_hv_clock_msr ( ) ;
}
2020-09-24 18:11:17 +03:00
static u64 notrace read_hv_sched_clock_msr ( void )
2019-07-01 07:26:06 +03:00
{
2020-03-27 05:11:59 +03:00
return ( read_hv_clock_msr ( ) - hv_sched_clock_offset ) *
( NSEC_PER_SEC / HV_CLOCK_HZ ) ;
2019-07-01 07:26:06 +03:00
}
static struct clocksource hyperv_cs_msr = {
. name = " hyperv_clocksource_msr " ,
2020-01-09 19:06:50 +03:00
. rating = 250 ,
2020-01-09 19:06:49 +03:00
. read = read_hv_clock_msr_cs ,
2019-07-01 07:26:06 +03:00
. mask = CLOCKSOURCE_MASK ( 64 ) ,
. flags = CLOCK_SOURCE_IS_CONTINUOUS ,
} ;
static bool __init hv_init_tsc_clocksource ( void )
{
u64 tsc_msr ;
phys_addr_t phys_addr ;
if ( ! ( ms_hyperv . features & HV_MSR_REFERENCE_TSC_AVAILABLE ) )
return false ;
2021-02-03 18:04:23 +03:00
if ( hv_root_partition )
return false ;
2020-01-09 19:06:49 +03:00
hv_read_reference_counter = read_hv_clock_tsc ;
clocksource/drivers/hyper-v: Reserve PAGE_SIZE space for tsc page
Currently, the reserved size for a tsc page is 4K, which is enough for
communicating with hypervisor. However, in the case where we want to
export the tsc page to userspace (e.g. for vDSO to read the
clocksource), the tsc page should be at least PAGE_SIZE, otherwise, when
PAGE_SIZE is larger than 4K, extra kernel data will be mapped into
userspace, which means leaking kernel information.
Therefore reserve PAGE_SIZE space for tsc_pg as a preparation for the
vDSO support of ARM64 in the future. Also, while at it, replace all
reference to tsc_pg with hv_get_tsc_page() since it should be the only
interface to access tsc page.
Signed-off-by: Boqun Feng (Microsoft) <boqun.feng@gmail.com>
Cc: linux-hyperv@vger.kernel.org
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20191126021723.4710-1-boqun.feng@gmail.com
2019-11-26 05:17:20 +03:00
phys_addr = virt_to_phys ( hv_get_tsc_page ( ) ) ;
2019-07-01 07:26:06 +03:00
/*
* The Hyper - V TLFS specifies to preserve the value of reserved
* bits in registers . So read the existing value , preserve the
* low order 12 bits , and add in the guest physical address
* ( which already has at least the low 12 bits set to zero since
* it is page aligned ) . Also set the " enable " bit , which is bit 0.
*/
hv_get_reference_tsc ( tsc_msr ) ;
tsc_msr & = GENMASK_ULL ( 11 , 0 ) ;
tsc_msr = tsc_msr | 0x1 | ( u64 ) phys_addr ;
hv_set_reference_tsc ( tsc_msr ) ;
hv_set_clocksource_vdso ( hyperv_cs_tsc ) ;
clocksource_register_hz ( & hyperv_cs_tsc , NSEC_PER_SEC / 100 ) ;
2020-01-09 19:06:49 +03:00
hv_sched_clock_offset = hv_read_reference_counter ( ) ;
2019-08-14 15:32:16 +03:00
hv_setup_sched_clock ( read_hv_sched_clock_tsc ) ;
2019-07-01 07:26:06 +03:00
return true ;
}
void __init hv_init_clocksource ( void )
{
/*
* Try to set up the TSC page clocksource . If it succeeds , we ' re
* done . Otherwise , set up the MSR clocksoruce . At least one of
* these will always be available except on very old versions of
* Hyper - V on x86 . In that case we won ' t have a Hyper - V
* clocksource , but Linux will still run with a clocksource based
* on the emulated PIT or LAPIC timer .
*/
if ( hv_init_tsc_clocksource ( ) )
return ;
if ( ! ( ms_hyperv . features & HV_MSR_TIME_REF_COUNT_AVAILABLE ) )
return ;
2020-01-09 19:06:49 +03:00
hv_read_reference_counter = read_hv_clock_msr ;
2019-07-01 07:26:06 +03:00
clocksource_register_hz ( & hyperv_cs_msr , NSEC_PER_SEC / 100 ) ;
2020-01-09 19:06:49 +03:00
hv_sched_clock_offset = hv_read_reference_counter ( ) ;
2019-08-14 15:32:16 +03:00
hv_setup_sched_clock ( read_hv_sched_clock_msr ) ;
2019-07-01 07:26:06 +03:00
}
EXPORT_SYMBOL_GPL ( hv_init_clocksource ) ;
