From: Marc Zyngier <maz@kernel.org>
To: Jianyong Wu <jianyong.wu@arm.com>
Cc: justin.he@arm.com, kvm@vger.kernel.org, netdev@vger.kernel.org,
richardcochran@gmail.com, linux-kernel@vger.kernel.org,
sean.j.christopherson@intel.com, steven.price@arm.com,
john.stultz@linaro.org, yangbo.lu@nxp.com, pbonzini@redhat.com,
tglx@linutronix.de, nd@arm.com, will@kernel.org,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v9 7/8] ptp: arm64: Enable ptp_kvm for arm64
Date: Tue, 07 Jan 2020 09:29:29 +0000 [thread overview]
Message-ID: <ca162efb3a0de530e119f5237c006515@kernel.org> (raw)
In-Reply-To: <20191210034026.45229-8-jianyong.wu@arm.com>
On 2019-12-10 03:40, Jianyong Wu wrote:
> Currently in arm64 virtualization environment, there is no mechanism to
> keep time sync between guest and host. Time in guest will drift
> compared
> with host after boot up as they may both use third party time sources
> to correct their time respectively. The time deviation will be in order
> of milliseconds but some scenarios ask for higher time precision, like
> in cloud envirenment, we want all the VMs running in the host aquire
> the
> same level accuracy from host clock.
>
> Use of kvm ptp clock, which choose the host clock source clock as a
> reference clock to sync time clock between guest and host has been
> adopted
> by x86 which makes the time sync order from milliseconds to
> nanoseconds.
>
> This patch enable kvm ptp on arm64 and we get the similar clock drift
> as
> found with x86 with kvm ptp.
>
> Test result comparison between with kvm ptp and without it in arm64 are
> as follows. This test derived from the result of command 'chronyc
> sources'. we should take more cure of the last sample column which
> shows
> the offset between the local clock and the source at the last
> measurement.
>
> no kvm ptp in guest:
> MS Name/IP address Stratum Poll Reach LastRx Last sample
> ========================================================================
> ^* dns1.synet.edu.cn 2 6 377 13 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 21 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 29 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 37 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 45 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 53 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 61 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 4 -130us[ +796us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 12 -130us[ +796us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 20 -130us[ +796us] +/-
> 21ms
>
> in host:
> MS Name/IP address Stratum Poll Reach LastRx Last sample
> ========================================================================
> ^* 120.25.115.20 2 7 377 72 -470us[ -603us] +/-
> 18ms
> ^* 120.25.115.20 2 7 377 92 -470us[ -603us] +/-
> 18ms
> ^* 120.25.115.20 2 7 377 112 -470us[ -603us] +/-
> 18ms
> ^* 120.25.115.20 2 7 377 2 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 22 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 43 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 63 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 83 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 103 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 123 +872ns[-6808ns] +/-
> 17ms
>
> The dns1.synet.edu.cn is the network reference clock for guest and
> 120.25.115.20 is the network reference clock for host. we can't get the
> clock error between guest and host directly, but a roughly estimated
> value
> will be in order of hundreds of us to ms.
>
> with kvm ptp in guest:
> chrony has been disabled in host to remove the disturb by network
> clock.
>
> MS Name/IP address Stratum Poll Reach LastRx Last sample
> ========================================================================
> * PHC0 0 3 377 8 -7ns[ +1ns] +/-
> 3ns
> * PHC0 0 3 377 8 +1ns[ +16ns] +/-
> 3ns
> * PHC0 0 3 377 6 -4ns[ -0ns] +/-
> 6ns
> * PHC0 0 3 377 6 -8ns[ -12ns] +/-
> 5ns
> * PHC0 0 3 377 5 +2ns[ +4ns] +/-
> 4ns
> * PHC0 0 3 377 13 +2ns[ +4ns] +/-
> 4ns
> * PHC0 0 3 377 12 -4ns[ -6ns] +/-
> 4ns
> * PHC0 0 3 377 11 -8ns[ -11ns] +/-
> 6ns
> * PHC0 0 3 377 10 -14ns[ -20ns] +/-
> 4ns
> * PHC0 0 3 377 8 +4ns[ +5ns] +/-
> 4ns
>
> The PHC0 is the ptp clock which choose the host clock as its source
> clock. So we can be sure to say that the clock error between host and
> guest
> is in order of ns.
>
> Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
> ---
> drivers/clocksource/arm_arch_timer.c | 22 ++++++++++++
> drivers/ptp/Kconfig | 2 +-
> drivers/ptp/ptp_kvm_arm64.c | 53 ++++++++++++++++++++++++++++
> 3 files changed, 76 insertions(+), 1 deletion(-)
> create mode 100644 drivers/ptp/ptp_kvm_arm64.c
>
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index 277846decd33..72260b66f02e 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -1636,3 +1636,25 @@ static int __init arch_timer_acpi_init(struct
> acpi_table_header *table)
> }
> TIMER_ACPI_DECLARE(arch_timer, ACPI_SIG_GTDT, arch_timer_acpi_init);
> #endif
> +
> +#if IS_ENABLED(CONFIG_PTP_1588_CLOCK_KVM)
> +#include <linux/arm-smccc.h>
> +int kvm_arch_ptp_get_crosststamp(unsigned long *cycle, struct
> timespec64 *ts,
> + struct clocksource **cs)
> +{
> + struct arm_smccc_res hvc_res;
> + ktime_t ktime_overall;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID, &hvc_res);
> + if ((long)(hvc_res.a0) < 0)
> + return -EOPNOTSUPP;
> +
> + ktime_overall = hvc_res.a0 << 32 | hvc_res.a1;
> + *ts = ktime_to_timespec64(ktime_overall);
> + *cycle = hvc_res.a2 << 32 | hvc_res.a3;
So why isn't that just a read of the virtual counter, given that what
you do
in the hypervisor seems to be "cntpct - cntvoff"?
What am I missing here?
> + *cs = &clocksource_counter;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(kvm_arch_ptp_get_crosststamp);
> +#endif
> diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
> index 9b8fee5178e8..3c31ff8eb05f 100644
> --- a/drivers/ptp/Kconfig
> +++ b/drivers/ptp/Kconfig
> @@ -110,7 +110,7 @@ config PTP_1588_CLOCK_PCH
> config PTP_1588_CLOCK_KVM
> tristate "KVM virtual PTP clock"
> depends on PTP_1588_CLOCK
> - depends on KVM_GUEST && X86
> + depends on KVM_GUEST && X86 || ARM64 && ARM_ARCH_TIMER
> default y
> help
> This driver adds support for using kvm infrastructure as a PTP
> diff --git a/drivers/ptp/ptp_kvm_arm64.c b/drivers/ptp/ptp_kvm_arm64.c
> new file mode 100644
> index 000000000000..f3f957117865
> --- /dev/null
> +++ b/drivers/ptp/ptp_kvm_arm64.c
> @@ -0,0 +1,53 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Virtual PTP 1588 clock for use with KVM guests
> + * Copyright (C) 2019 ARM Ltd.
> + * All Rights Reserved
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/err.h>
> +#include <asm/hypervisor.h>
> +#include <linux/module.h>
> +#include <linux/psci.h>
> +#include <linux/arm-smccc.h>
> +#include <linux/timecounter.h>
> +#include <linux/sched/clock.h>
> +#include <asm/arch_timer.h>
> +
> +int kvm_arch_ptp_init(void)
> +{
> + struct arm_smccc_res hvc_res;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID,
> + &hvc_res);
> + if ((long)(hvc_res.a0) < 0)
> + return -EOPNOTSUPP;
> +
> + return 0;
> +}
> +
> +int kvm_arch_ptp_get_clock_generic(struct timespec64 *ts,
> + struct arm_smccc_res *hvc_res)
> +{
> + ktime_t ktime_overall;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID,
> + hvc_res);
> + if ((long)(hvc_res->a0) < 0)
> + return -EOPNOTSUPP;
> +
> + ktime_overall = hvc_res->a0 << 32 | hvc_res->a1;
> + *ts = ktime_to_timespec64(ktime_overall);
> +
> + return 0;
> +}
> +
> +int kvm_arch_ptp_get_clock(struct timespec64 *ts)
> +{
> + struct arm_smccc_res hvc_res;
> +
> + kvm_arch_ptp_get_clock_generic(ts, &hvc_res);
> +
> + return 0;
> +}
I also wonder why this is all arm64 specific, while everything
should also work just fine on 32bit.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Jianyong Wu <jianyong.wu@arm.com>
Cc: Mark.Rutland@arm.com, justin.he@arm.com, kvm@vger.kernel.org,
suzuki.poulose@arm.com, netdev@vger.kernel.org,
richardcochran@gmail.com, Steve.Capper@arm.com,
linux-kernel@vger.kernel.org, sean.j.christopherson@intel.com,
steven.price@arm.com, Kaly.Xin@arm.com, john.stultz@linaro.org,
yangbo.lu@nxp.com, pbonzini@redhat.com, tglx@linutronix.de,
nd@arm.com, will@kernel.org, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v9 7/8] ptp: arm64: Enable ptp_kvm for arm64
Date: Tue, 07 Jan 2020 09:29:29 +0000 [thread overview]
Message-ID: <ca162efb3a0de530e119f5237c006515@kernel.org> (raw)
In-Reply-To: <20191210034026.45229-8-jianyong.wu@arm.com>
On 2019-12-10 03:40, Jianyong Wu wrote:
> Currently in arm64 virtualization environment, there is no mechanism to
> keep time sync between guest and host. Time in guest will drift
> compared
> with host after boot up as they may both use third party time sources
> to correct their time respectively. The time deviation will be in order
> of milliseconds but some scenarios ask for higher time precision, like
> in cloud envirenment, we want all the VMs running in the host aquire
> the
> same level accuracy from host clock.
>
> Use of kvm ptp clock, which choose the host clock source clock as a
> reference clock to sync time clock between guest and host has been
> adopted
> by x86 which makes the time sync order from milliseconds to
> nanoseconds.
>
> This patch enable kvm ptp on arm64 and we get the similar clock drift
> as
> found with x86 with kvm ptp.
>
> Test result comparison between with kvm ptp and without it in arm64 are
> as follows. This test derived from the result of command 'chronyc
> sources'. we should take more cure of the last sample column which
> shows
> the offset between the local clock and the source at the last
> measurement.
>
> no kvm ptp in guest:
> MS Name/IP address Stratum Poll Reach LastRx Last sample
> ========================================================================
> ^* dns1.synet.edu.cn 2 6 377 13 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 21 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 29 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 37 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 45 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 53 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 61 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 4 -130us[ +796us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 12 -130us[ +796us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 20 -130us[ +796us] +/-
> 21ms
>
> in host:
> MS Name/IP address Stratum Poll Reach LastRx Last sample
> ========================================================================
> ^* 120.25.115.20 2 7 377 72 -470us[ -603us] +/-
> 18ms
> ^* 120.25.115.20 2 7 377 92 -470us[ -603us] +/-
> 18ms
> ^* 120.25.115.20 2 7 377 112 -470us[ -603us] +/-
> 18ms
> ^* 120.25.115.20 2 7 377 2 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 22 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 43 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 63 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 83 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 103 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 123 +872ns[-6808ns] +/-
> 17ms
>
> The dns1.synet.edu.cn is the network reference clock for guest and
> 120.25.115.20 is the network reference clock for host. we can't get the
> clock error between guest and host directly, but a roughly estimated
> value
> will be in order of hundreds of us to ms.
>
> with kvm ptp in guest:
> chrony has been disabled in host to remove the disturb by network
> clock.
>
> MS Name/IP address Stratum Poll Reach LastRx Last sample
> ========================================================================
> * PHC0 0 3 377 8 -7ns[ +1ns] +/-
> 3ns
> * PHC0 0 3 377 8 +1ns[ +16ns] +/-
> 3ns
> * PHC0 0 3 377 6 -4ns[ -0ns] +/-
> 6ns
> * PHC0 0 3 377 6 -8ns[ -12ns] +/-
> 5ns
> * PHC0 0 3 377 5 +2ns[ +4ns] +/-
> 4ns
> * PHC0 0 3 377 13 +2ns[ +4ns] +/-
> 4ns
> * PHC0 0 3 377 12 -4ns[ -6ns] +/-
> 4ns
> * PHC0 0 3 377 11 -8ns[ -11ns] +/-
> 6ns
> * PHC0 0 3 377 10 -14ns[ -20ns] +/-
> 4ns
> * PHC0 0 3 377 8 +4ns[ +5ns] +/-
> 4ns
>
> The PHC0 is the ptp clock which choose the host clock as its source
> clock. So we can be sure to say that the clock error between host and
> guest
> is in order of ns.
>
> Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
> ---
> drivers/clocksource/arm_arch_timer.c | 22 ++++++++++++
> drivers/ptp/Kconfig | 2 +-
> drivers/ptp/ptp_kvm_arm64.c | 53 ++++++++++++++++++++++++++++
> 3 files changed, 76 insertions(+), 1 deletion(-)
> create mode 100644 drivers/ptp/ptp_kvm_arm64.c
>
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index 277846decd33..72260b66f02e 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -1636,3 +1636,25 @@ static int __init arch_timer_acpi_init(struct
> acpi_table_header *table)
> }
> TIMER_ACPI_DECLARE(arch_timer, ACPI_SIG_GTDT, arch_timer_acpi_init);
> #endif
> +
> +#if IS_ENABLED(CONFIG_PTP_1588_CLOCK_KVM)
> +#include <linux/arm-smccc.h>
> +int kvm_arch_ptp_get_crosststamp(unsigned long *cycle, struct
> timespec64 *ts,
> + struct clocksource **cs)
> +{
> + struct arm_smccc_res hvc_res;
> + ktime_t ktime_overall;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID, &hvc_res);
> + if ((long)(hvc_res.a0) < 0)
> + return -EOPNOTSUPP;
> +
> + ktime_overall = hvc_res.a0 << 32 | hvc_res.a1;
> + *ts = ktime_to_timespec64(ktime_overall);
> + *cycle = hvc_res.a2 << 32 | hvc_res.a3;
So why isn't that just a read of the virtual counter, given that what
you do
in the hypervisor seems to be "cntpct - cntvoff"?
What am I missing here?
> + *cs = &clocksource_counter;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(kvm_arch_ptp_get_crosststamp);
> +#endif
> diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
> index 9b8fee5178e8..3c31ff8eb05f 100644
> --- a/drivers/ptp/Kconfig
> +++ b/drivers/ptp/Kconfig
> @@ -110,7 +110,7 @@ config PTP_1588_CLOCK_PCH
> config PTP_1588_CLOCK_KVM
> tristate "KVM virtual PTP clock"
> depends on PTP_1588_CLOCK
> - depends on KVM_GUEST && X86
> + depends on KVM_GUEST && X86 || ARM64 && ARM_ARCH_TIMER
> default y
> help
> This driver adds support for using kvm infrastructure as a PTP
> diff --git a/drivers/ptp/ptp_kvm_arm64.c b/drivers/ptp/ptp_kvm_arm64.c
> new file mode 100644
> index 000000000000..f3f957117865
> --- /dev/null
> +++ b/drivers/ptp/ptp_kvm_arm64.c
> @@ -0,0 +1,53 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Virtual PTP 1588 clock for use with KVM guests
> + * Copyright (C) 2019 ARM Ltd.
> + * All Rights Reserved
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/err.h>
> +#include <asm/hypervisor.h>
> +#include <linux/module.h>
> +#include <linux/psci.h>
> +#include <linux/arm-smccc.h>
> +#include <linux/timecounter.h>
> +#include <linux/sched/clock.h>
> +#include <asm/arch_timer.h>
> +
> +int kvm_arch_ptp_init(void)
> +{
> + struct arm_smccc_res hvc_res;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID,
> + &hvc_res);
> + if ((long)(hvc_res.a0) < 0)
> + return -EOPNOTSUPP;
> +
> + return 0;
> +}
> +
> +int kvm_arch_ptp_get_clock_generic(struct timespec64 *ts,
> + struct arm_smccc_res *hvc_res)
> +{
> + ktime_t ktime_overall;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID,
> + hvc_res);
> + if ((long)(hvc_res->a0) < 0)
> + return -EOPNOTSUPP;
> +
> + ktime_overall = hvc_res->a0 << 32 | hvc_res->a1;
> + *ts = ktime_to_timespec64(ktime_overall);
> +
> + return 0;
> +}
> +
> +int kvm_arch_ptp_get_clock(struct timespec64 *ts)
> +{
> + struct arm_smccc_res hvc_res;
> +
> + kvm_arch_ptp_get_clock_generic(ts, &hvc_res);
> +
> + return 0;
> +}
I also wonder why this is all arm64 specific, while everything
should also work just fine on 32bit.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Jianyong Wu <jianyong.wu@arm.com>
Cc: netdev@vger.kernel.org, yangbo.lu@nxp.com,
john.stultz@linaro.org, tglx@linutronix.de, pbonzini@redhat.com,
sean.j.christopherson@intel.com, richardcochran@gmail.com,
Mark.Rutland@arm.com, will@kernel.org, suzuki.poulose@arm.com,
steven.price@arm.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
Steve.Capper@arm.com, Kaly.Xin@arm.com, justin.he@arm.com,
nd@arm.com
Subject: Re: [RFC PATCH v9 7/8] ptp: arm64: Enable ptp_kvm for arm64
Date: Tue, 07 Jan 2020 09:29:29 +0000 [thread overview]
Message-ID: <ca162efb3a0de530e119f5237c006515@kernel.org> (raw)
In-Reply-To: <20191210034026.45229-8-jianyong.wu@arm.com>
On 2019-12-10 03:40, Jianyong Wu wrote:
> Currently in arm64 virtualization environment, there is no mechanism to
> keep time sync between guest and host. Time in guest will drift
> compared
> with host after boot up as they may both use third party time sources
> to correct their time respectively. The time deviation will be in order
> of milliseconds but some scenarios ask for higher time precision, like
> in cloud envirenment, we want all the VMs running in the host aquire
> the
> same level accuracy from host clock.
>
> Use of kvm ptp clock, which choose the host clock source clock as a
> reference clock to sync time clock between guest and host has been
> adopted
> by x86 which makes the time sync order from milliseconds to
> nanoseconds.
>
> This patch enable kvm ptp on arm64 and we get the similar clock drift
> as
> found with x86 with kvm ptp.
>
> Test result comparison between with kvm ptp and without it in arm64 are
> as follows. This test derived from the result of command 'chronyc
> sources'. we should take more cure of the last sample column which
> shows
> the offset between the local clock and the source at the last
> measurement.
>
> no kvm ptp in guest:
> MS Name/IP address Stratum Poll Reach LastRx Last sample
> ========================================================================
> ^* dns1.synet.edu.cn 2 6 377 13 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 21 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 29 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 37 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 45 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 53 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 61 +1040us[+1581us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 4 -130us[ +796us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 12 -130us[ +796us] +/-
> 21ms
> ^* dns1.synet.edu.cn 2 6 377 20 -130us[ +796us] +/-
> 21ms
>
> in host:
> MS Name/IP address Stratum Poll Reach LastRx Last sample
> ========================================================================
> ^* 120.25.115.20 2 7 377 72 -470us[ -603us] +/-
> 18ms
> ^* 120.25.115.20 2 7 377 92 -470us[ -603us] +/-
> 18ms
> ^* 120.25.115.20 2 7 377 112 -470us[ -603us] +/-
> 18ms
> ^* 120.25.115.20 2 7 377 2 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 22 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 43 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 63 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 83 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 103 +872ns[-6808ns] +/-
> 17ms
> ^* 120.25.115.20 2 7 377 123 +872ns[-6808ns] +/-
> 17ms
>
> The dns1.synet.edu.cn is the network reference clock for guest and
> 120.25.115.20 is the network reference clock for host. we can't get the
> clock error between guest and host directly, but a roughly estimated
> value
> will be in order of hundreds of us to ms.
>
> with kvm ptp in guest:
> chrony has been disabled in host to remove the disturb by network
> clock.
>
> MS Name/IP address Stratum Poll Reach LastRx Last sample
> ========================================================================
> * PHC0 0 3 377 8 -7ns[ +1ns] +/-
> 3ns
> * PHC0 0 3 377 8 +1ns[ +16ns] +/-
> 3ns
> * PHC0 0 3 377 6 -4ns[ -0ns] +/-
> 6ns
> * PHC0 0 3 377 6 -8ns[ -12ns] +/-
> 5ns
> * PHC0 0 3 377 5 +2ns[ +4ns] +/-
> 4ns
> * PHC0 0 3 377 13 +2ns[ +4ns] +/-
> 4ns
> * PHC0 0 3 377 12 -4ns[ -6ns] +/-
> 4ns
> * PHC0 0 3 377 11 -8ns[ -11ns] +/-
> 6ns
> * PHC0 0 3 377 10 -14ns[ -20ns] +/-
> 4ns
> * PHC0 0 3 377 8 +4ns[ +5ns] +/-
> 4ns
>
> The PHC0 is the ptp clock which choose the host clock as its source
> clock. So we can be sure to say that the clock error between host and
> guest
> is in order of ns.
>
> Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
> ---
> drivers/clocksource/arm_arch_timer.c | 22 ++++++++++++
> drivers/ptp/Kconfig | 2 +-
> drivers/ptp/ptp_kvm_arm64.c | 53 ++++++++++++++++++++++++++++
> 3 files changed, 76 insertions(+), 1 deletion(-)
> create mode 100644 drivers/ptp/ptp_kvm_arm64.c
>
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index 277846decd33..72260b66f02e 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -1636,3 +1636,25 @@ static int __init arch_timer_acpi_init(struct
> acpi_table_header *table)
> }
> TIMER_ACPI_DECLARE(arch_timer, ACPI_SIG_GTDT, arch_timer_acpi_init);
> #endif
> +
> +#if IS_ENABLED(CONFIG_PTP_1588_CLOCK_KVM)
> +#include <linux/arm-smccc.h>
> +int kvm_arch_ptp_get_crosststamp(unsigned long *cycle, struct
> timespec64 *ts,
> + struct clocksource **cs)
> +{
> + struct arm_smccc_res hvc_res;
> + ktime_t ktime_overall;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID, &hvc_res);
> + if ((long)(hvc_res.a0) < 0)
> + return -EOPNOTSUPP;
> +
> + ktime_overall = hvc_res.a0 << 32 | hvc_res.a1;
> + *ts = ktime_to_timespec64(ktime_overall);
> + *cycle = hvc_res.a2 << 32 | hvc_res.a3;
So why isn't that just a read of the virtual counter, given that what
you do
in the hypervisor seems to be "cntpct - cntvoff"?
What am I missing here?
> + *cs = &clocksource_counter;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(kvm_arch_ptp_get_crosststamp);
> +#endif
> diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
> index 9b8fee5178e8..3c31ff8eb05f 100644
> --- a/drivers/ptp/Kconfig
> +++ b/drivers/ptp/Kconfig
> @@ -110,7 +110,7 @@ config PTP_1588_CLOCK_PCH
> config PTP_1588_CLOCK_KVM
> tristate "KVM virtual PTP clock"
> depends on PTP_1588_CLOCK
> - depends on KVM_GUEST && X86
> + depends on KVM_GUEST && X86 || ARM64 && ARM_ARCH_TIMER
> default y
> help
> This driver adds support for using kvm infrastructure as a PTP
> diff --git a/drivers/ptp/ptp_kvm_arm64.c b/drivers/ptp/ptp_kvm_arm64.c
> new file mode 100644
> index 000000000000..f3f957117865
> --- /dev/null
> +++ b/drivers/ptp/ptp_kvm_arm64.c
> @@ -0,0 +1,53 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Virtual PTP 1588 clock for use with KVM guests
> + * Copyright (C) 2019 ARM Ltd.
> + * All Rights Reserved
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/err.h>
> +#include <asm/hypervisor.h>
> +#include <linux/module.h>
> +#include <linux/psci.h>
> +#include <linux/arm-smccc.h>
> +#include <linux/timecounter.h>
> +#include <linux/sched/clock.h>
> +#include <asm/arch_timer.h>
> +
> +int kvm_arch_ptp_init(void)
> +{
> + struct arm_smccc_res hvc_res;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID,
> + &hvc_res);
> + if ((long)(hvc_res.a0) < 0)
> + return -EOPNOTSUPP;
> +
> + return 0;
> +}
> +
> +int kvm_arch_ptp_get_clock_generic(struct timespec64 *ts,
> + struct arm_smccc_res *hvc_res)
> +{
> + ktime_t ktime_overall;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID,
> + hvc_res);
> + if ((long)(hvc_res->a0) < 0)
> + return -EOPNOTSUPP;
> +
> + ktime_overall = hvc_res->a0 << 32 | hvc_res->a1;
> + *ts = ktime_to_timespec64(ktime_overall);
> +
> + return 0;
> +}
> +
> +int kvm_arch_ptp_get_clock(struct timespec64 *ts)
> +{
> + struct arm_smccc_res hvc_res;
> +
> + kvm_arch_ptp_get_clock_generic(ts, &hvc_res);
> +
> + return 0;
> +}
I also wonder why this is all arm64 specific, while everything
should also work just fine on 32bit.
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2020-01-07 9:29 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-10 3:40 [RFC PATCH v9 0/8] Enable ptp_kvm for arm64 Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2019-12-10 3:40 ` [RFC PATCH v9 1/8] arm/arm64: smccc/psci: add arm_smccc_1_1_get_conduit() Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2019-12-10 3:40 ` [RFC PATCH v9 2/8] psci: let arm_smccc_1_1_invoke available by modules Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2019-12-10 3:40 ` [RFC PATCH v9 3/8] ptp: Reorganize ptp_kvm modules to make it arch-independent Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2019-12-10 3:40 ` [RFC PATCH v9 4/8] time: Add mechanism to recognize clocksource in time_get_snapshot Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2019-12-10 3:40 ` [RFC PATCH v9 5/8] clocksource: Add clocksource id for arm arch counter Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2019-12-10 3:40 ` [RFC PATCH v9 6/8] psci: Add hvc call service for ptp_kvm Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2020-01-07 9:16 ` Marc Zyngier
2020-01-07 9:16 ` Marc Zyngier
2020-01-07 9:16 ` Marc Zyngier
2020-01-09 5:45 ` Jianyong Wu
2020-01-09 5:45 ` Jianyong Wu
2020-01-09 5:45 ` Jianyong Wu
2020-01-09 9:16 ` Marc Zyngier
2020-01-09 9:16 ` Marc Zyngier
2020-01-09 9:16 ` Marc Zyngier
2020-01-10 9:51 ` Jianyong Wu
2020-01-10 9:51 ` Jianyong Wu
2020-01-10 9:51 ` Jianyong Wu
2020-01-10 10:56 ` Marc Zyngier
2020-01-10 10:56 ` Marc Zyngier
2020-01-10 10:56 ` Marc Zyngier
2020-01-13 10:30 ` Jianyong Wu
2020-01-13 10:30 ` Jianyong Wu
2020-01-13 10:30 ` Jianyong Wu
2020-01-13 11:16 ` Marc Zyngier
2020-01-13 11:16 ` Marc Zyngier
2020-01-13 11:16 ` Marc Zyngier
2020-01-14 10:34 ` Jianyong Wu
2020-01-14 10:34 ` Jianyong Wu
2020-01-14 10:34 ` Jianyong Wu
2019-12-10 3:40 ` [RFC PATCH v9 7/8] ptp: arm64: Enable ptp_kvm for arm64 Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2020-01-07 9:29 ` Marc Zyngier [this message]
2020-01-07 9:29 ` Marc Zyngier
2020-01-07 9:29 ` Marc Zyngier
2020-01-09 5:59 ` Jianyong Wu
2020-01-09 5:59 ` Jianyong Wu
2020-01-09 5:59 ` Jianyong Wu
2020-01-09 9:24 ` Marc Zyngier
2020-01-09 9:24 ` Marc Zyngier
2020-01-09 9:24 ` Marc Zyngier
2020-01-09 9:46 ` Marc Zyngier
2020-01-09 9:46 ` Marc Zyngier
2020-01-09 9:46 ` Marc Zyngier
2020-01-10 10:15 ` Jianyong Wu
2020-01-10 10:15 ` Jianyong Wu
2020-01-10 10:15 ` Jianyong Wu
2020-01-10 10:15 ` Jianyong Wu
2020-01-10 10:15 ` Jianyong Wu
2020-01-10 10:15 ` Jianyong Wu
2020-01-10 10:35 ` Marc Zyngier
2020-01-10 10:35 ` Marc Zyngier
2020-01-10 10:35 ` Marc Zyngier
2020-01-13 10:37 ` Jianyong Wu
2020-01-13 10:37 ` Jianyong Wu
2020-01-13 10:37 ` Jianyong Wu
2020-01-13 11:21 ` Marc Zyngier
2020-01-13 11:21 ` Marc Zyngier
2020-01-13 11:21 ` Marc Zyngier
2020-01-14 10:22 ` Jianyong Wu
2020-01-14 10:22 ` Jianyong Wu
2020-01-14 10:22 ` Jianyong Wu
2019-12-10 3:40 ` [RFC PATCH v9 8/8] kvm: arm64: Add capability check extension for ptp_kvm Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2019-12-10 3:40 ` Jianyong Wu
2020-01-06 9:38 ` [RFC PATCH v9 0/8] Enable ptp_kvm for arm64 Jianyong Wu
2020-01-06 9:38 ` Jianyong Wu
2020-01-06 9:38 ` Jianyong Wu
2020-01-07 8:15 ` Paolo Bonzini
2020-01-07 8:15 ` Paolo Bonzini
2020-01-07 8:15 ` Paolo Bonzini
2020-01-07 9:33 ` Marc Zyngier
2020-01-07 9:33 ` Marc Zyngier
2020-01-07 9:33 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ca162efb3a0de530e119f5237c006515@kernel.org \
--to=maz@kernel.org \
--cc=jianyong.wu@arm.com \
--cc=john.stultz@linaro.org \
--cc=justin.he@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nd@arm.com \
--cc=netdev@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=richardcochran@gmail.com \
--cc=sean.j.christopherson@intel.com \
--cc=steven.price@arm.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=yangbo.lu@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.