* [PATCH v5 1/6] psci: Export psci_ops.conduit symbol as modules will use it.
2019-10-15 10:48 [RFC PATCH v5 0/6] Enable ptp_kvm for arm64 Jianyong Wu
@ 2019-10-15 10:48 ` Jianyong Wu
2019-10-15 17:24 ` Mark Rutland
2019-10-15 10:48 ` [PATCH v5 2/6] ptp: Reorganize ptp_kvm modules to make it arch-independent Jianyong Wu
` (4 subsequent siblings)
5 siblings, 1 reply; 30+ messages in thread
From: Jianyong Wu @ 2019-10-15 10:48 UTC (permalink / raw)
To: netdev, yangbo.lu, john.stultz, tglx, pbonzini,
sean.j.christopherson, maz, richardcochran, Mark.Rutland, will,
suzuki.poulose
Cc: justin.he, kvm, jianyong.wu, linux-kernel, nd, kvmarm, linux-arm-kernel
If arm_smccc_1_1_invoke used in modules, psci_ops.conduit should
be export.
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
---
drivers/firmware/psci/psci.c | 6 ++++++
include/linux/arm-smccc.h | 2 +-
include/linux/psci.h | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index f82ccd39a913..35c4eaab1451 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -212,6 +212,12 @@ static unsigned long psci_migrate_info_up_cpu(void)
0, 0, 0);
}
+enum psci_conduit psci_get_conduit(void)
+{
+ return psci_ops.conduit;
+}
+EXPORT_SYMBOL(psci_get_conduit);
+
static void set_conduit(enum psci_conduit conduit)
{
switch (conduit) {
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 552cbd49abe8..a6e4d3e3d10a 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -357,7 +357,7 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
* The return value also provides the conduit that was used.
*/
#define arm_smccc_1_1_invoke(...) ({ \
- int method = psci_ops.conduit; \
+ int method = psci_get_conduit(); \
switch (method) { \
case PSCI_CONDUIT_HVC: \
arm_smccc_1_1_hvc(__VA_ARGS__); \
diff --git a/include/linux/psci.h b/include/linux/psci.h
index a8a15613c157..e5cedc986049 100644
--- a/include/linux/psci.h
+++ b/include/linux/psci.h
@@ -42,6 +42,7 @@ struct psci_operations {
enum smccc_version smccc_version;
};
+extern enum psci_conduit psci_get_conduit(void);
extern struct psci_operations psci_ops;
#if defined(CONFIG_ARM_PSCI_FW)
--
2.17.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH v5 1/6] psci: Export psci_ops.conduit symbol as modules will use it.
2019-10-15 10:48 ` [PATCH v5 1/6] psci: Export psci_ops.conduit symbol as modules will use it Jianyong Wu
@ 2019-10-15 17:24 ` Mark Rutland
2019-10-16 3:54 ` Jianyong Wu (Arm Technology China)
0 siblings, 1 reply; 30+ messages in thread
From: Mark Rutland @ 2019-10-15 17:24 UTC (permalink / raw)
To: Jianyong Wu
Cc: maz, justin.he, kvm, netdev, richardcochran, linux-kernel,
sean.j.christopherson, john.stultz, yangbo.lu, pbonzini, tglx,
nd, will, kvmarm, linux-arm-kernel
On Tue, Oct 15, 2019 at 06:48:17PM +0800, Jianyong Wu wrote:
> If arm_smccc_1_1_invoke used in modules, psci_ops.conduit should
> be export.
>
> Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
I have a patch queued [1] in the arm64 tree which adds
arm_smccc_1_1_get_conduit() for this purpose.
Please use that, adding an EXPORT_SYMBOL() if necessary.
Thanks,
Mark.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?h=for-next/smccc-conduit-cleanup&id=6b7fe77c334ae59fed9500140e08f4f896b36871
> ---
> drivers/firmware/psci/psci.c | 6 ++++++
> include/linux/arm-smccc.h | 2 +-
> include/linux/psci.h | 1 +
> 3 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index f82ccd39a913..35c4eaab1451 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -212,6 +212,12 @@ static unsigned long psci_migrate_info_up_cpu(void)
> 0, 0, 0);
> }
>
> +enum psci_conduit psci_get_conduit(void)
> +{
> + return psci_ops.conduit;
> +}
> +EXPORT_SYMBOL(psci_get_conduit);
> +
> static void set_conduit(enum psci_conduit conduit)
> {
> switch (conduit) {
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index 552cbd49abe8..a6e4d3e3d10a 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -357,7 +357,7 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
> * The return value also provides the conduit that was used.
> */
> #define arm_smccc_1_1_invoke(...) ({ \
> - int method = psci_ops.conduit; \
> + int method = psci_get_conduit(); \
> switch (method) { \
> case PSCI_CONDUIT_HVC: \
> arm_smccc_1_1_hvc(__VA_ARGS__); \
> diff --git a/include/linux/psci.h b/include/linux/psci.h
> index a8a15613c157..e5cedc986049 100644
> --- a/include/linux/psci.h
> +++ b/include/linux/psci.h
> @@ -42,6 +42,7 @@ struct psci_operations {
> enum smccc_version smccc_version;
> };
>
> +extern enum psci_conduit psci_get_conduit(void);
> extern struct psci_operations psci_ops;
>
> #if defined(CONFIG_ARM_PSCI_FW)
> --
> 2.17.1
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* RE: [PATCH v5 1/6] psci: Export psci_ops.conduit symbol as modules will use it.
2019-10-15 17:24 ` Mark Rutland
@ 2019-10-16 3:54 ` Jianyong Wu (Arm Technology China)
0 siblings, 0 replies; 30+ messages in thread
From: Jianyong Wu (Arm Technology China) @ 2019-10-16 3:54 UTC (permalink / raw)
To: Mark Rutland
Cc: maz, Justin He (Arm Technology China),
kvm, netdev, richardcochran, linux-kernel, sean.j.christopherson,
john.stultz, yangbo.lu, pbonzini, tglx, nd, will, kvmarm,
linux-arm-kernel
Hi Mark,
> -----Original Message-----
> From: Mark Rutland <mark.rutland@arm.com>
> Sent: Wednesday, October 16, 2019 1:25 AM
> To: Jianyong Wu (Arm Technology China) <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;
> maz@kernel.org; richardcochran@gmail.com; will@kernel.org; Suzuki
> Poulose <Suzuki.Poulose@arm.com>; linux-kernel@vger.kernel.org; linux-
> arm-kernel@lists.infradead.org; kvmarm@lists.cs.columbia.edu;
> kvm@vger.kernel.org; Steve Capper <Steve.Capper@arm.com>; Kaly Xin
> (Arm Technology China) <Kaly.Xin@arm.com>; Justin He (Arm Technology
> China) <Justin.He@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v5 1/6] psci: Export psci_ops.conduit symbol as modules
> will use it.
>
> On Tue, Oct 15, 2019 at 06:48:17PM +0800, Jianyong Wu wrote:
> > If arm_smccc_1_1_invoke used in modules, psci_ops.conduit should be
> > export.
> >
> > Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
>
> I have a patch queued [1] in the arm64 tree which adds
> arm_smccc_1_1_get_conduit() for this purpose.
>
> Please use that, adding an EXPORT_SYMBOL() if necessary.
>
Great, I will apply it next version.
Thanks
Jianyong Wu
> Thanks,
> Mark.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?h=
> for-next/smccc-conduit-
> cleanup&id=6b7fe77c334ae59fed9500140e08f4f896b36871
>
> > ---
> > drivers/firmware/psci/psci.c | 6 ++++++
> > include/linux/arm-smccc.h | 2 +-
> > include/linux/psci.h | 1 +
> > 3 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/psci/psci.c
> > b/drivers/firmware/psci/psci.c index f82ccd39a913..35c4eaab1451 100644
> > --- a/drivers/firmware/psci/psci.c
> > +++ b/drivers/firmware/psci/psci.c
> > @@ -212,6 +212,12 @@ static unsigned long
> psci_migrate_info_up_cpu(void)
> > 0, 0, 0);
> > }
> >
> > +enum psci_conduit psci_get_conduit(void) {
> > + return psci_ops.conduit;
> > +}
> > +EXPORT_SYMBOL(psci_get_conduit);
> > +
> > static void set_conduit(enum psci_conduit conduit) {
> > switch (conduit) {
> > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> > index 552cbd49abe8..a6e4d3e3d10a 100644
> > --- a/include/linux/arm-smccc.h
> > +++ b/include/linux/arm-smccc.h
> > @@ -357,7 +357,7 @@ asmlinkage void __arm_smccc_hvc(unsigned long
> a0, unsigned long a1,
> > * The return value also provides the conduit that was used.
> > */
> > #define arm_smccc_1_1_invoke(...) ({
> \
> > - int method = psci_ops.conduit; \
> > + int method = psci_get_conduit(); \
> > switch (method) { \
> > case PSCI_CONDUIT_HVC:
> \
> > arm_smccc_1_1_hvc(__VA_ARGS__);
> \
> > diff --git a/include/linux/psci.h b/include/linux/psci.h index
> > a8a15613c157..e5cedc986049 100644
> > --- a/include/linux/psci.h
> > +++ b/include/linux/psci.h
> > @@ -42,6 +42,7 @@ struct psci_operations {
> > enum smccc_version smccc_version;
> > };
> >
> > +extern enum psci_conduit psci_get_conduit(void);
> > extern struct psci_operations psci_ops;
> >
> > #if defined(CONFIG_ARM_PSCI_FW)
> > --
> > 2.17.1
> >
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v5 2/6] ptp: Reorganize ptp_kvm modules to make it arch-independent.
2019-10-15 10:48 [RFC PATCH v5 0/6] Enable ptp_kvm for arm64 Jianyong Wu
2019-10-15 10:48 ` [PATCH v5 1/6] psci: Export psci_ops.conduit symbol as modules will use it Jianyong Wu
@ 2019-10-15 10:48 ` Jianyong Wu
2019-10-16 7:10 ` Paolo Bonzini
2019-10-15 10:48 ` [PATCH v5 3/6] timekeeping: Add clocksource to system_time_snapshot Jianyong Wu
` (3 subsequent siblings)
5 siblings, 1 reply; 30+ messages in thread
From: Jianyong Wu @ 2019-10-15 10:48 UTC (permalink / raw)
To: netdev, yangbo.lu, john.stultz, tglx, pbonzini,
sean.j.christopherson, maz, richardcochran, Mark.Rutland, will,
suzuki.poulose
Cc: justin.he, kvm, jianyong.wu, linux-kernel, nd, kvmarm, linux-arm-kernel
Currently, ptp_kvm modules implementation is only for x86 which includs
large part of arch-specific code. This patch move all of those code
into new arch related file in the same directory.
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
---
drivers/ptp/Makefile | 1 +
drivers/ptp/{ptp_kvm.c => ptp_kvm_common.c} | 77 +++++-------------
drivers/ptp/ptp_kvm_x86.c | 87 +++++++++++++++++++++
include/asm-generic/ptp_kvm.h | 12 +++
4 files changed, 118 insertions(+), 59 deletions(-)
rename drivers/ptp/{ptp_kvm.c => ptp_kvm_common.c} (63%)
create mode 100644 drivers/ptp/ptp_kvm_x86.c
create mode 100644 include/asm-generic/ptp_kvm.h
diff --git a/drivers/ptp/Makefile b/drivers/ptp/Makefile
index 677d1d178a3e..8f27ba302e31 100644
--- a/drivers/ptp/Makefile
+++ b/drivers/ptp/Makefile
@@ -4,6 +4,7 @@
#
ptp-y := ptp_clock.o ptp_chardev.o ptp_sysfs.o
+ptp_kvm-y := ptp_kvm_$(ARCH).o kvm_ptp.o
obj-$(CONFIG_PTP_1588_CLOCK) += ptp.o
obj-$(CONFIG_PTP_1588_CLOCK_DTE) += ptp_dte.o
obj-$(CONFIG_PTP_1588_CLOCK_IXP46X) += ptp_ixp46x.o
diff --git a/drivers/ptp/ptp_kvm.c b/drivers/ptp/ptp_kvm_common.c
similarity index 63%
rename from drivers/ptp/ptp_kvm.c
rename to drivers/ptp/ptp_kvm_common.c
index fc7d0b77e118..d8f215186904 100644
--- a/drivers/ptp/ptp_kvm.c
+++ b/drivers/ptp/ptp_kvm_common.c
@@ -8,12 +8,12 @@
#include <linux/err.h>
#include <linux/init.h>
#include <linux/kernel.h>
+#include <linux/slab.h>
#include <linux/module.h>
#include <uapi/linux/kvm_para.h>
#include <asm/kvm_para.h>
-#include <asm/pvclock.h>
-#include <asm/kvmclock.h>
#include <uapi/asm/kvm_para.h>
+#include <asm-generic/ptp_kvm.h>
#include <linux/ptp_clock_kernel.h>
@@ -24,56 +24,29 @@ struct kvm_ptp_clock {
DEFINE_SPINLOCK(kvm_ptp_lock);
-static struct pvclock_vsyscall_time_info *hv_clock;
-
-static struct kvm_clock_pairing clock_pair;
-static phys_addr_t clock_pair_gpa;
-
static int ptp_kvm_get_time_fn(ktime_t *device_time,
struct system_counterval_t *system_counter,
void *ctx)
{
- unsigned long ret;
+ unsigned long ret, cycle;
struct timespec64 tspec;
- unsigned version;
- int cpu;
- struct pvclock_vcpu_time_info *src;
+ struct clocksource *cs;
spin_lock(&kvm_ptp_lock);
preempt_disable_notrace();
- cpu = smp_processor_id();
- src = &hv_clock[cpu].pvti;
-
- do {
- /*
- * We are using a TSC value read in the hosts
- * kvm_hc_clock_pairing handling.
- * So any changes to tsc_to_system_mul
- * and tsc_shift or any other pvclock
- * data invalidate that measurement.
- */
- version = pvclock_read_begin(src);
-
- ret = kvm_hypercall2(KVM_HC_CLOCK_PAIRING,
- clock_pair_gpa,
- KVM_CLOCK_PAIRING_WALLCLOCK);
- if (ret != 0) {
- pr_err_ratelimited("clock pairing hypercall ret %lu\n", ret);
- spin_unlock(&kvm_ptp_lock);
- preempt_enable_notrace();
- return -EOPNOTSUPP;
- }
-
- tspec.tv_sec = clock_pair.sec;
- tspec.tv_nsec = clock_pair.nsec;
- ret = __pvclock_read_cycles(src, clock_pair.tsc);
- } while (pvclock_read_retry(src, version));
+ ret = kvm_arch_ptp_get_clock_fn(&cycle, &tspec, &cs);
+ if (ret != 0) {
+ pr_err_ratelimited("clock pairing hypercall ret %lu\n", ret);
+ spin_unlock(&kvm_ptp_lock);
+ preempt_enable_notrace();
+ return -EOPNOTSUPP;
+ }
preempt_enable_notrace();
- system_counter->cycles = ret;
- system_counter->cs = &kvm_clock;
+ system_counter->cycles = cycle;
+ system_counter->cs = cs;
*device_time = timespec64_to_ktime(tspec);
@@ -116,17 +89,13 @@ static int ptp_kvm_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
spin_lock(&kvm_ptp_lock);
- ret = kvm_hypercall2(KVM_HC_CLOCK_PAIRING,
- clock_pair_gpa,
- KVM_CLOCK_PAIRING_WALLCLOCK);
+ ret = kvm_arch_ptp_get_clock(&tspec);
if (ret != 0) {
pr_err_ratelimited("clock offset hypercall ret %lu\n", ret);
spin_unlock(&kvm_ptp_lock);
return -EOPNOTSUPP;
}
- tspec.tv_sec = clock_pair.sec;
- tspec.tv_nsec = clock_pair.nsec;
spin_unlock(&kvm_ptp_lock);
memcpy(ts, &tspec, sizeof(struct timespec64));
@@ -166,21 +135,11 @@ static void __exit ptp_kvm_exit(void)
static int __init ptp_kvm_init(void)
{
- long ret;
-
- if (!kvm_para_available())
- return -ENODEV;
-
- clock_pair_gpa = slow_virt_to_phys(&clock_pair);
- hv_clock = pvclock_get_pvti_cpu0_va();
+ int ret;
- if (!hv_clock)
- return -ENODEV;
-
- ret = kvm_hypercall2(KVM_HC_CLOCK_PAIRING, clock_pair_gpa,
- KVM_CLOCK_PAIRING_WALLCLOCK);
- if (ret == -KVM_ENOSYS || ret == -KVM_EOPNOTSUPP)
- return -ENODEV;
+ ret = kvm_arch_ptp_init();
+ if (!ret)
+ return -EOPNOTSUPP;
kvm_ptp_clock.caps = ptp_kvm_caps;
diff --git a/drivers/ptp/ptp_kvm_x86.c b/drivers/ptp/ptp_kvm_x86.c
new file mode 100644
index 000000000000..a52cf1c2990c
--- /dev/null
+++ b/drivers/ptp/ptp_kvm_x86.c
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Virtual PTP 1588 clock for use with KVM guests
+ *
+ * Copyright (C) 2017 Red Hat Inc.
+ */
+
+#include <asm/pvclock.h>
+#include <asm/kvmclock.h>
+#include <linux/module.h>
+#include <uapi/asm/kvm_para.h>
+#include <uapi/linux/kvm_para.h>
+#include <linux/ptp_clock_kernel.h>
+
+phys_addr_t clock_pair_gpa;
+struct kvm_clock_pairing clock_pair;
+struct pvclock_vsyscall_time_info *hv_clock;
+
+int kvm_arch_ptp_init(void)
+{
+ int ret;
+
+ if (!kvm_para_available())
+ return -ENODEV;
+
+ clock_pair_gpa = slow_virt_to_phys(&clock_pair);
+ hv_clock = pvclock_get_pvti_cpu0_va();
+ if (!hv_clock)
+ return -ENODEV;
+
+ ret = kvm_hypercall2(KVM_HC_CLOCK_PAIRING, clock_pair_gpa,
+ KVM_CLOCK_PAIRING_WALLCLOCK);
+ if (ret == -KVM_ENOSYS || ret == -KVM_EOPNOTSUPP)
+ return -ENODEV;
+
+ return 0;
+}
+
+int kvm_arch_ptp_get_clock(struct timespec64 *ts)
+{
+ long ret;
+
+ ret = kvm_hypercall2(KVM_HC_CLOCK_PAIRING,
+ clock_pair_gpa,
+ KVM_CLOCK_PAIRING_WALLCLOCK);
+ if (ret != 0)
+ return -EOPNOTSUPP;
+
+ ts->tv_sec = clock_pair.sec;
+ ts->tv_nsec = clock_pair.nsec;
+
+ return 0;
+}
+
+int kvm_arch_ptp_get_clock_fn(unsigned long *cycle, struct timespec64 *tspec,
+ struct clocksource **cs)
+{
+ unsigned long ret;
+ unsigned int version;
+ int cpu;
+ struct pvclock_vcpu_time_info *src;
+
+ cpu = smp_processor_id();
+ src = &hv_clock[cpu].pvti;
+
+ do {
+ /*
+ * We are using a TSC value read in the hosts
+ * kvm_hc_clock_pairing handling.
+ * So any changes to tsc_to_system_mul
+ * and tsc_shift or any other pvclock
+ * data invalidate that measurement.
+ */
+ version = pvclock_read_begin(src);
+
+ ret = kvm_hypercall2(KVM_HC_CLOCK_PAIRING,
+ clock_pair_gpa,
+ KVM_CLOCK_PAIRING_WALLCLOCK);
+ tspec->tv_sec = clock_pair.sec;
+ tspec->tv_nsec = clock_pair.nsec;
+ *cycle = __pvclock_read_cycles(src, clock_pair.tsc);
+ } while (pvclock_read_retry(src, version));
+
+ *cs = &kvm_clock;
+
+ return 0;
+}
diff --git a/include/asm-generic/ptp_kvm.h b/include/asm-generic/ptp_kvm.h
new file mode 100644
index 000000000000..829d76bdb905
--- /dev/null
+++ b/include/asm-generic/ptp_kvm.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Virtual PTP 1588 clock for use with KVM guests
+ *
+ * Copyright (C) 2019 ARM Ltd.
+ * All Rights Reserved
+ */
+
+int kvm_arch_ptp_init(void);
+int kvm_arch_ptp_get_clock(struct timespec64 *ts);
+int kvm_arch_ptp_get_clock_fn(unsigned long *cycle,
+ struct timespec64 *tspec, void *cs);
--
2.17.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH v5 2/6] ptp: Reorganize ptp_kvm modules to make it arch-independent.
2019-10-15 10:48 ` [PATCH v5 2/6] ptp: Reorganize ptp_kvm modules to make it arch-independent Jianyong Wu
@ 2019-10-16 7:10 ` Paolo Bonzini
2019-10-16 10:04 ` Jianyong Wu (Arm Technology China)
0 siblings, 1 reply; 30+ messages in thread
From: Paolo Bonzini @ 2019-10-16 7:10 UTC (permalink / raw)
To: Jianyong Wu, netdev, yangbo.lu, john.stultz, tglx,
sean.j.christopherson, maz, richardcochran, Mark.Rutland, will,
suzuki.poulose
Cc: justin.he, kvm, linux-kernel, nd, kvmarm, linux-arm-kernel
On 15/10/19 12:48, Jianyong Wu wrote:
> + ret = kvm_arch_ptp_init();
> + if (!ret)
> + return -EOPNOTSUPP;
This should be "if (ret)".
Paolo
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v5 2/6] ptp: Reorganize ptp_kvm modules to make it arch-independent.
2019-10-16 7:10 ` Paolo Bonzini
@ 2019-10-16 10:04 ` Jianyong Wu (Arm Technology China)
0 siblings, 0 replies; 30+ messages in thread
From: Jianyong Wu (Arm Technology China) @ 2019-10-16 10:04 UTC (permalink / raw)
To: Paolo Bonzini, netdev, yangbo.lu, john.stultz, tglx,
sean.j.christopherson, maz, richardcochran, Mark Rutland, will,
Suzuki Poulose
Cc: Justin He (Arm Technology China),
kvm, linux-kernel, nd, kvmarm, linux-arm-kernel
Hi Paolo,
> -----Original Message-----
> From: Paolo Bonzini <pbonzini@redhat.com>
> Sent: Wednesday, October 16, 2019 3:10 PM
> To: Jianyong Wu (Arm Technology China) <Jianyong.Wu@arm.com>;
> netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org;
> tglx@linutronix.de; sean.j.christopherson@intel.com; maz@kernel.org;
> richardcochran@gmail.com; Mark Rutland <Mark.Rutland@arm.com>;
> will@kernel.org; Suzuki Poulose <Suzuki.Poulose@arm.com>
> Cc: linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org; Steve Capper
> <Steve.Capper@arm.com>; Kaly Xin (Arm Technology China)
> <Kaly.Xin@arm.com>; Justin He (Arm Technology China)
> <Justin.He@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v5 2/6] ptp: Reorganize ptp_kvm modules to make it
> arch-independent.
>
> On 15/10/19 12:48, Jianyong Wu wrote:
> > + ret = kvm_arch_ptp_init();
> > + if (!ret)
> > + return -EOPNOTSUPP;
>
> This should be "if (ret)".
>
Yeah, I change this at patch 5/6, but need change it here.
Thanks
Jianyong
> Paolo
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v5 3/6] timekeeping: Add clocksource to system_time_snapshot
2019-10-15 10:48 [RFC PATCH v5 0/6] Enable ptp_kvm for arm64 Jianyong Wu
2019-10-15 10:48 ` [PATCH v5 1/6] psci: Export psci_ops.conduit symbol as modules will use it Jianyong Wu
2019-10-15 10:48 ` [PATCH v5 2/6] ptp: Reorganize ptp_kvm modules to make it arch-independent Jianyong Wu
@ 2019-10-15 10:48 ` Jianyong Wu
2019-10-15 16:37 ` Paolo Bonzini
2019-10-15 20:12 ` Thomas Gleixner
2019-10-15 10:48 ` [PATCH v5 4/6] psci: Add hvc call service for ptp_kvm Jianyong Wu
` (2 subsequent siblings)
5 siblings, 2 replies; 30+ messages in thread
From: Jianyong Wu @ 2019-10-15 10:48 UTC (permalink / raw)
To: netdev, yangbo.lu, john.stultz, tglx, pbonzini,
sean.j.christopherson, maz, richardcochran, Mark.Rutland, will,
suzuki.poulose
Cc: justin.he, kvm, jianyong.wu, linux-kernel, nd, kvmarm, linux-arm-kernel
Sometimes, we need check current clocksource outside of
timekeeping area. Add clocksource to system_time_snapshot then
we can get clocksource as well as system time.
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
---
include/linux/timekeeping.h | 35 ++++++++++++++++++-----------------
kernel/time/timekeeping.c | 7 ++++---
2 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index a8ab0f143ac4..964c14fbbf69 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -194,23 +194,6 @@ extern bool timekeeping_rtc_skipresume(void);
extern void timekeeping_inject_sleeptime64(const struct timespec64 *delta);
-/*
- * struct system_time_snapshot - simultaneous raw/real time capture with
- * counter value
- * @cycles: Clocksource counter value to produce the system times
- * @real: Realtime system time
- * @raw: Monotonic raw system time
- * @clock_was_set_seq: The sequence number of clock was set events
- * @cs_was_changed_seq: The sequence number of clocksource change events
- */
-struct system_time_snapshot {
- u64 cycles;
- ktime_t real;
- ktime_t raw;
- unsigned int clock_was_set_seq;
- u8 cs_was_changed_seq;
-};
-
/*
* struct system_device_crosststamp - system/device cross-timestamp
* (syncronized capture)
@@ -236,6 +219,24 @@ struct system_counterval_t {
struct clocksource *cs;
};
+/*
+ * struct system_time_snapshot - simultaneous raw/real time capture with
+ * counter value
+ * @sc: Contains clocksource and clocksource counter value to produce
+ * the system times
+ * @real: Realtime system time
+ * @raw: Monotonic raw system time
+ * @clock_was_set_seq: The sequence number of clock was set events
+ * @cs_was_changed_seq: The sequence number of clocksource change events
+ */
+struct system_time_snapshot {
+ struct system_counterval_t sc;
+ ktime_t real;
+ ktime_t raw;
+ unsigned int clock_was_set_seq;
+ u8 cs_was_changed_seq;
+};
+
/*
* Get cross timestamp between system clock and device clock
*/
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 44b726bab4bd..66ff089605b3 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -983,7 +983,8 @@ void ktime_get_snapshot(struct system_time_snapshot *systime_snapshot)
nsec_raw = timekeeping_cycles_to_ns(&tk->tkr_raw, now);
} while (read_seqcount_retry(&tk_core.seq, seq));
- systime_snapshot->cycles = now;
+ systime_snapshot->sc.cycles = now;
+ systime_snapshot->sc.cs = tk->tkr_mono.clock;
systime_snapshot->real = ktime_add_ns(base_real, nsec_real);
systime_snapshot->raw = ktime_add_ns(base_raw, nsec_raw);
}
@@ -1189,12 +1190,12 @@ int get_device_system_crosststamp(int (*get_time_fn)
* clocksource change
*/
if (!history_begin ||
- !cycle_between(history_begin->cycles,
+ !cycle_between(history_begin->sc.cycles,
system_counterval.cycles, cycles) ||
history_begin->cs_was_changed_seq != cs_was_changed_seq)
return -EINVAL;
partial_history_cycles = cycles - system_counterval.cycles;
- total_history_cycles = cycles - history_begin->cycles;
+ total_history_cycles = cycles - history_begin->sc.cycles;
discontinuity =
history_begin->clock_was_set_seq != clock_was_set_seq;
--
2.17.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH v5 3/6] timekeeping: Add clocksource to system_time_snapshot
2019-10-15 10:48 ` [PATCH v5 3/6] timekeeping: Add clocksource to system_time_snapshot Jianyong Wu
@ 2019-10-15 16:37 ` Paolo Bonzini
2019-10-15 20:13 ` Thomas Gleixner
2019-10-15 20:12 ` Thomas Gleixner
1 sibling, 1 reply; 30+ messages in thread
From: Paolo Bonzini @ 2019-10-15 16:37 UTC (permalink / raw)
To: Jianyong Wu, netdev, yangbo.lu, john.stultz, tglx,
sean.j.christopherson, maz, richardcochran, Mark.Rutland, will,
suzuki.poulose
Cc: justin.he, kvm, linux-kernel, nd, kvmarm, linux-arm-kernel
On 15/10/19 12:48, Jianyong Wu wrote:
> Sometimes, we need check current clocksource outside of
> timekeeping area. Add clocksource to system_time_snapshot then
> we can get clocksource as well as system time.
>
> Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
> Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> include/linux/timekeeping.h | 35 ++++++++++++++++++-----------------
> kernel/time/timekeeping.c | 7 ++++---
> 2 files changed, 22 insertions(+), 20 deletions(-)
>
> diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
> index a8ab0f143ac4..964c14fbbf69 100644
> --- a/include/linux/timekeeping.h
> +++ b/include/linux/timekeeping.h
> @@ -194,23 +194,6 @@ extern bool timekeeping_rtc_skipresume(void);
>
> extern void timekeeping_inject_sleeptime64(const struct timespec64 *delta);
>
> -/*
> - * struct system_time_snapshot - simultaneous raw/real time capture with
> - * counter value
> - * @cycles: Clocksource counter value to produce the system times
> - * @real: Realtime system time
> - * @raw: Monotonic raw system time
> - * @clock_was_set_seq: The sequence number of clock was set events
> - * @cs_was_changed_seq: The sequence number of clocksource change events
> - */
> -struct system_time_snapshot {
> - u64 cycles;
> - ktime_t real;
> - ktime_t raw;
> - unsigned int clock_was_set_seq;
> - u8 cs_was_changed_seq;
> -};
> -
> /*
> * struct system_device_crosststamp - system/device cross-timestamp
> * (syncronized capture)
> @@ -236,6 +219,24 @@ struct system_counterval_t {
> struct clocksource *cs;
> };
>
> +/*
> + * struct system_time_snapshot - simultaneous raw/real time capture with
> + * counter value
> + * @sc: Contains clocksource and clocksource counter value to produce
> + * the system times
> + * @real: Realtime system time
> + * @raw: Monotonic raw system time
> + * @clock_was_set_seq: The sequence number of clock was set events
> + * @cs_was_changed_seq: The sequence number of clocksource change events
> + */
> +struct system_time_snapshot {
> + struct system_counterval_t sc;
> + ktime_t real;
> + ktime_t raw;
> + unsigned int clock_was_set_seq;
> + u8 cs_was_changed_seq;
> +};
> +
> /*
> * Get cross timestamp between system clock and device clock
> */
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 44b726bab4bd..66ff089605b3 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -983,7 +983,8 @@ void ktime_get_snapshot(struct system_time_snapshot *systime_snapshot)
> nsec_raw = timekeeping_cycles_to_ns(&tk->tkr_raw, now);
> } while (read_seqcount_retry(&tk_core.seq, seq));
>
> - systime_snapshot->cycles = now;
> + systime_snapshot->sc.cycles = now;
> + systime_snapshot->sc.cs = tk->tkr_mono.clock;
> systime_snapshot->real = ktime_add_ns(base_real, nsec_real);
> systime_snapshot->raw = ktime_add_ns(base_raw, nsec_raw);
> }
> @@ -1189,12 +1190,12 @@ int get_device_system_crosststamp(int (*get_time_fn)
> * clocksource change
> */
> if (!history_begin ||
> - !cycle_between(history_begin->cycles,
> + !cycle_between(history_begin->sc.cycles,
> system_counterval.cycles, cycles) ||
> history_begin->cs_was_changed_seq != cs_was_changed_seq)
> return -EINVAL;
> partial_history_cycles = cycles - system_counterval.cycles;
> - total_history_cycles = cycles - history_begin->cycles;
> + total_history_cycles = cycles - history_begin->sc.cycles;
> discontinuity =
> history_begin->clock_was_set_seq != clock_was_set_seq;
>
>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH v5 3/6] timekeeping: Add clocksource to system_time_snapshot
2019-10-15 16:37 ` Paolo Bonzini
@ 2019-10-15 20:13 ` Thomas Gleixner
2019-10-15 22:36 ` Paolo Bonzini
0 siblings, 1 reply; 30+ messages in thread
From: Thomas Gleixner @ 2019-10-15 20:13 UTC (permalink / raw)
To: Paolo Bonzini
Cc: justin.he, kvm, maz, richardcochran, Jianyong Wu, linux-kernel,
sean.j.christopherson, yangbo.lu, john.stultz, netdev, nd, will,
kvmarm, linux-arm-kernel
On Tue, 15 Oct 2019, Paolo Bonzini wrote:
> On 15/10/19 12:48, Jianyong Wu wrote:
> >
> >
>
> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
You're sure about having reviewed that in detail?
Thanks,
tglx
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 3/6] timekeeping: Add clocksource to system_time_snapshot
2019-10-15 20:13 ` Thomas Gleixner
@ 2019-10-15 22:36 ` Paolo Bonzini
2019-10-16 7:28 ` Thomas Gleixner
0 siblings, 1 reply; 30+ messages in thread
From: Paolo Bonzini @ 2019-10-15 22:36 UTC (permalink / raw)
To: Thomas Gleixner
Cc: justin.he, kvm, maz, richardcochran, Jianyong Wu, linux-kernel,
sean.j.christopherson, yangbo.lu, john.stultz, netdev, nd, will,
kvmarm, linux-arm-kernel
On 15/10/19 22:13, Thomas Gleixner wrote:
> On Tue, 15 Oct 2019, Paolo Bonzini wrote:
>> On 15/10/19 12:48, Jianyong Wu wrote:
>>>
>>>
>>
>> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
>
> You're sure about having reviewed that in detail?
I did review the patch; the void* ugliness is not in this one, and I do
have some other qualms on that one.
> This changelog is telling absolutely nothing WHY anything outside of the
> timekeeping core code needs access to the current clocksource. Neither does
> it tell why it is safe to provide the pointer to random callers.
Agreed on the changelog, but the pointer to a clocksource is already
part of the timekeeping external API via struct system_counterval_t.
get_device_system_crosststamp for example expects a clocksource pointer
but provides no way to get such a pointer.
Paolo
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 3/6] timekeeping: Add clocksource to system_time_snapshot
2019-10-15 22:36 ` Paolo Bonzini
@ 2019-10-16 7:28 ` Thomas Gleixner
2019-10-16 9:48 ` Jianyong Wu (Arm Technology China)
0 siblings, 1 reply; 30+ messages in thread
From: Thomas Gleixner @ 2019-10-16 7:28 UTC (permalink / raw)
To: Paolo Bonzini
Cc: justin.he, kvm, maz, richardcochran, Jianyong Wu, linux-kernel,
sean.j.christopherson, yangbo.lu, john.stultz, netdev, nd, will,
kvmarm, linux-arm-kernel
On Wed, 16 Oct 2019, Paolo Bonzini wrote:
> On 15/10/19 22:13, Thomas Gleixner wrote:
> > On Tue, 15 Oct 2019, Paolo Bonzini wrote:
> >> On 15/10/19 12:48, Jianyong Wu wrote:
> >>>
> >>>
> >>
> >> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
> >
> > You're sure about having reviewed that in detail?
>
> I did review the patch; the void* ugliness is not in this one, and I do
> have some other qualms on that one.
>
> > This changelog is telling absolutely nothing WHY anything outside of the
> > timekeeping core code needs access to the current clocksource. Neither does
> > it tell why it is safe to provide the pointer to random callers.
>
> Agreed on the changelog, but the pointer to a clocksource is already
> part of the timekeeping external API via struct system_counterval_t.
> get_device_system_crosststamp for example expects a clocksource pointer
> but provides no way to get such a pointer.
That's a completely different beast, really.
The clocksource pointer is handed in by the caller and the core code
validates if the clocksource is the same as the current system clocksource
and not the other way round.
So there is no need for getting that pointer from the core code because the
caller knows already which clocksource needs to be active to make.the whole
cross device timestamp correlation work. And in that case it's the callers
responsibility to ensure that the pointer is valid which is the case for
the current use cases.
From your other reply:
> Why add a global id? ARM can add it to archdata similar to how x86 has
> vclock_mode. But I still think the right thing to do is to include the
> full system_counterval_t in the result of ktime_get_snapshot. (More in
> a second, feel free to reply to the other email only).
No, the clocksource pointer is not going to be exposed as there is no
guarantee that it will be still around after the call returns.
It's not even guaranteed to be correct when the store happens in Wu's patch
simply because the store is done outside of the seqcount protected region.
Vs. arch data: arch data is an opaque struct, so you'd need to store a
pointer which has the same issue as the clocksource pointer itself.
If we want to convey information then it has to be in the generic part
of struct clocksource.
In fact we could even simplify the existing get_device_system_crosststamp()
use case by using the ID field.
Thanks,
tglx
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v5 3/6] timekeeping: Add clocksource to system_time_snapshot
2019-10-16 7:28 ` Thomas Gleixner
@ 2019-10-16 9:48 ` Jianyong Wu (Arm Technology China)
2019-10-16 10:23 ` Thomas Gleixner
0 siblings, 1 reply; 30+ messages in thread
From: Jianyong Wu (Arm Technology China) @ 2019-10-16 9:48 UTC (permalink / raw)
To: Thomas Gleixner, Paolo Bonzini
Cc: Justin He (Arm Technology China),
kvm, maz, richardcochran, yangbo.lu, linux-kernel,
sean.j.christopherson, john.stultz, netdev, nd, will, kvmarm,
linux-arm-kernel
Hi tglx,
> -----Original Message-----
> From: Thomas Gleixner <tglx@linutronix.de>
> Sent: Wednesday, October 16, 2019 3:29 PM
> To: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Jianyong Wu (Arm Technology China) <Jianyong.Wu@arm.com>;
> netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org;
> sean.j.christopherson@intel.com; maz@kernel.org;
> richardcochran@gmail.com; Mark Rutland <Mark.Rutland@arm.com>;
> will@kernel.org; Suzuki Poulose <Suzuki.Poulose@arm.com>; linux-
> kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org; Steve Capper
> <Steve.Capper@arm.com>; Kaly Xin (Arm Technology China)
> <Kaly.Xin@arm.com>; Justin He (Arm Technology China)
> <Justin.He@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v5 3/6] timekeeping: Add clocksource to
> system_time_snapshot
>
> On Wed, 16 Oct 2019, Paolo Bonzini wrote:
> > On 15/10/19 22:13, Thomas Gleixner wrote:
> > > On Tue, 15 Oct 2019, Paolo Bonzini wrote:
> > >> On 15/10/19 12:48, Jianyong Wu wrote:
> > >>>
> > >>>
> > >>
> > >> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
> > >
> > > You're sure about having reviewed that in detail?
> >
> > I did review the patch; the void* ugliness is not in this one, and I
> > do have some other qualms on that one.
> >
> > > This changelog is telling absolutely nothing WHY anything outside of
> > > the timekeeping core code needs access to the current clocksource.
> > > Neither does it tell why it is safe to provide the pointer to random callers.
> >
> > Agreed on the changelog, but the pointer to a clocksource is already
> > part of the timekeeping external API via struct system_counterval_t.
> > get_device_system_crosststamp for example expects a clocksource
> > pointer but provides no way to get such a pointer.
>
> That's a completely different beast, really.
>
> The clocksource pointer is handed in by the caller and the core code validates
> if the clocksource is the same as the current system clocksource and not the
> other way round.
>
> So there is no need for getting that pointer from the core code because the
> caller knows already which clocksource needs to be active to make.the whole
> cross device timestamp correlation work. And in that case it's the callers
> responsibility to ensure that the pointer is valid which is the case for the
> current use cases.
>
I thinks there is something misunderstanding of my patch. See patch 4/6, the reason why I add clocksource is that I want to check if the current clocksouce is
arm_arch_counter in virt/kvm/arm/psci.c and nothing to do with get_device_system_crosststamp.
So I really need a mechanism to do that check.
Thanks
Jianyong
> From your other reply:
>
> > Why add a global id? ARM can add it to archdata similar to how x86
> > has vclock_mode. But I still think the right thing to do is to
> > include the full system_counterval_t in the result of
> > ktime_get_snapshot. (More in a second, feel free to reply to the other
> email only).
>
> No, the clocksource pointer is not going to be exposed as there is no
> guarantee that it will be still around after the call returns.
>
> It's not even guaranteed to be correct when the store happens in Wu's patch
> simply because the store is done outside of the seqcount protected region.
Yeah, all of the elements in system_time_snapshot should be captured in consistency. So
I think the consistency will be guaranteed if the store ops added in the seqcount region.
>
> Vs. arch data: arch data is an opaque struct, so you'd need to store a pointer
> which has the same issue as the clocksource pointer itself.
>
> If we want to convey information then it has to be in the generic part of
> struct clocksource.
>
> In fact we could even simplify the existing get_device_system_crosststamp()
> use case by using the ID field.
>
> Thanks,
>
> tglx
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v5 3/6] timekeeping: Add clocksource to system_time_snapshot
2019-10-16 9:48 ` Jianyong Wu (Arm Technology China)
@ 2019-10-16 10:23 ` Thomas Gleixner
0 siblings, 0 replies; 30+ messages in thread
From: Thomas Gleixner @ 2019-10-16 10:23 UTC (permalink / raw)
To: Jianyong Wu (Arm Technology China)
Cc: Justin He (Arm Technology China),
kvm, maz, richardcochran, linux-kernel, sean.j.christopherson,
netdev, john.stultz, yangbo.lu, Paolo Bonzini, nd, will, kvmarm,
linux-arm-kernel
Jianyong,
On Wed, 16 Oct 2019, Jianyong Wu (Arm Technology China) wrote:
Please fix your mail client not to copy the full headers into the reply.
> > On Wed, 16 Oct 2019, Paolo Bonzini wrote:
> > > On 15/10/19 22:13, Thomas Gleixner wrote:
> > That's a completely different beast, really.
> >
> > The clocksource pointer is handed in by the caller and the core code validates
> > if the clocksource is the same as the current system clocksource and not the
> > other way round.
> >
> > So there is no need for getting that pointer from the core code because the
> > caller knows already which clocksource needs to be active to make.the whole
> > cross device timestamp correlation work. And in that case it's the callers
> > responsibility to ensure that the pointer is valid which is the case for the
> > current use cases.
> >
> I thinks there is something misunderstanding of my patch. See patch 4/6,
> the reason why I add clocksource is that I want to check if the current
> clocksouce is arm_arch_counter in virt/kvm/arm/psci.c and nothing to do
> with get_device_system_crosststamp.
There is no misunderstanding at all. Your patch is broken in several ways
as I explained in detail.
> So I really need a mechanism to do that check.
>
> Thanks
> Jianyong
So just by chance I scrolled further down and found more replies from
you. Please trim the reply properly and add your 'Thanks Jianyong' to the
end of the mail.
> > From your other reply:
> >
> > > Why add a global id? ARM can add it to archdata similar to how x86
> > > has vclock_mode. But I still think the right thing to do is to
> > > include the full system_counterval_t in the result of
> > > ktime_get_snapshot. (More in a second, feel free to reply to the other
> > email only).
> >
> > No, the clocksource pointer is not going to be exposed as there is no
> > guarantee that it will be still around after the call returns.
> >
> > It's not even guaranteed to be correct when the store happens in Wu's patch
> > simply because the store is done outside of the seqcount protected region.
>
> Yeah, all of the elements in system_time_snapshot should be captured in
> consistency. So I think the consistency will be guaranteed if the store
> ops added in the seqcount region.
Again. While it is consistent in terms of storage, it's still wrong to
expose a pointer to something which has no life time guarantee. Even if
your use case is just to compare the pointer it's a bad idea to do that
especially without any comment about the pointer validity at all.
Thanks,
tglx
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 3/6] timekeeping: Add clocksource to system_time_snapshot
2019-10-15 10:48 ` [PATCH v5 3/6] timekeeping: Add clocksource to system_time_snapshot Jianyong Wu
2019-10-15 16:37 ` Paolo Bonzini
@ 2019-10-15 20:12 ` Thomas Gleixner
2019-10-15 22:35 ` Paolo Bonzini
2019-10-16 10:01 ` Jianyong Wu (Arm Technology China)
1 sibling, 2 replies; 30+ messages in thread
From: Thomas Gleixner @ 2019-10-15 20:12 UTC (permalink / raw)
To: Jianyong Wu
Cc: justin.he, kvm, maz, richardcochran, yangbo.lu, linux-kernel,
sean.j.christopherson, john.stultz, netdev, pbonzini, nd, will,
kvmarm, linux-arm-kernel
On Tue, 15 Oct 2019, Jianyong Wu wrote:
> Sometimes, we need check current clocksource outside of
> timekeeping area. Add clocksource to system_time_snapshot then
> we can get clocksource as well as system time.
This changelog is telling absolutely nothing WHY anything outside of the
timekeeping core code needs access to the current clocksource. Neither does
it tell why it is safe to provide the pointer to random callers.
> +/*
> + * struct system_time_snapshot - simultaneous raw/real time capture with
> + * counter value
> + * @sc: Contains clocksource and clocksource counter value to produce
> + * the system times
> + * @real: Realtime system time
> + * @raw: Monotonic raw system time
> + * @clock_was_set_seq: The sequence number of clock was set events
> + * @cs_was_changed_seq: The sequence number of clocksource change events
> + */
> +struct system_time_snapshot {
> + struct system_counterval_t sc;
> + ktime_t real;
> + ktime_t raw;
> + unsigned int clock_was_set_seq;
> + u8 cs_was_changed_seq;
> +};
> +
> /*
> * Get cross timestamp between system clock and device clock
> */
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 44b726bab4bd..66ff089605b3 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -983,7 +983,8 @@ void ktime_get_snapshot(struct system_time_snapshot *systime_snapshot)
> nsec_raw = timekeeping_cycles_to_ns(&tk->tkr_raw, now);
> } while (read_seqcount_retry(&tk_core.seq, seq));
>
> - systime_snapshot->cycles = now;
> + systime_snapshot->sc.cycles = now;
> + systime_snapshot->sc.cs = tk->tkr_mono.clock;
The clock pointer can change right after the store, the underlying data can
be freed .....
Looking at the rest of the patch set the actual usage site is:
> + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> + ktime_get_snapshot(&systime_snapshot);
> + if (!is_arm_arch_counter(systime_snapshot.sc.cs))
> + return kvm_psci_call(vcpu);
and that function does:
> +bool is_arm_arch_counter(void *cs)
void *? Type safety is overrated, right? The type is well known....
+{
+ return (struct clocksource *)cs == &clocksource_counter;
That nonsensical typecast does not make up for that.
+}
So while the access to the pointer is actually safe, this is not going to
happen simply because you modify a generic interface in a way which will
lead the next developer to insane assumptions about the validity of that
pointer.
While the kernel is pretty lax in terms of isolation due to the nature of
the programming language, this does not justify to expose critical
internals of core code to random callers. Guess why most of the timekeeping
internals are carefully shielded from external access.
Something like the completely untested (not even compiled) patch below
gives you access to the information you need and allows to reuse the
mechanism for other purposes without adding is_$FOO_timer() all over the
place.
Thanks,
tglx
8<--------------
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -9,6 +9,7 @@
#ifndef _LINUX_CLOCKSOURCE_H
#define _LINUX_CLOCKSOURCE_H
+#include <linux/clocksource_ids.h>
#include <linux/types.h>
#include <linux/timex.h>
#include <linux/time.h>
@@ -49,6 +50,10 @@ struct module;
* 400-499: Perfect
* The ideal clocksource. A must-use where
* available.
+ * @id: Defaults to CSID_GENERIC. The id value is captured
+ * in certain snapshot functions to allow callers to
+ * validate the clocksource from which the snapshot was
+ * taken.
* @read: returns a cycle value, passes clocksource as argument
* @enable: optional function to enable the clocksource
* @disable: optional function to disable the clocksource
@@ -91,6 +96,7 @@ struct clocksource {
const char *name;
struct list_head list;
int rating;
+ enum clocksource_ids id;
int (*enable)(struct clocksource *cs);
void (*disable)(struct clocksource *cs);
unsigned long flags;
--- /dev/null
+++ b/include/linux/clocksource_ids.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_CLOCKSOURCE_IDS_H
+#define _LINUX_CLOCKSOURCE_IDS_H
+
+/* Enum to give clocksources a unique identifier */
+enum clocksource_ids {
+ CSID_GENERIC = 0,
+ CSID_ARM_ARCH_COUNTER,
+ CSID_MAX,
+};
+
+#endif
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -2,6 +2,7 @@
#ifndef _LINUX_TIMEKEEPING_H
#define _LINUX_TIMEKEEPING_H
+#include <linux/clocksource_ids.h>
#include <linux/errno.h>
/* Included from linux/ktime.h */
@@ -228,15 +229,17 @@ extern void timekeeping_inject_sleeptime
* @cycles: Clocksource counter value to produce the system times
* @real: Realtime system time
* @raw: Monotonic raw system time
+ * @cs_id: The id of the current clocksource which produced the snapshot
* @clock_was_set_seq: The sequence number of clock was set events
* @cs_was_changed_seq: The sequence number of clocksource change events
*/
struct system_time_snapshot {
- u64 cycles;
- ktime_t real;
- ktime_t raw;
- unsigned int clock_was_set_seq;
- u8 cs_was_changed_seq;
+ u64 cycles;
+ ktime_t real;
+ ktime_t raw;
+ enum clocksource_ids cs_id;
+ unsigned int clock_was_set_seq;
+ u8 cs_was_changed_seq;
};
/*
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -921,6 +921,9 @@ int __clocksource_register_scale(struct
clocksource_arch_init(cs);
+ if (WARN_ON_ONCE((unsigned int)cs->id >= CSID_MAX))
+ cs->id = CSID_GENERIC;
+
/* Initialize mult/shift and max_idle_ns */
__clocksource_update_freq_scale(cs, scale, freq);
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -979,6 +979,7 @@ void ktime_get_snapshot(struct system_ti
do {
seq = read_seqcount_begin(&tk_core.seq);
now = tk_clock_read(&tk->tkr_mono);
+ systime_snapshot->cs_id = tk->tkr_mono.clock->id;
systime_snapshot->cs_was_changed_seq = tk->cs_was_changed_seq;
systime_snapshot->clock_was_set_seq = tk->clock_was_set_seq;
base_real = ktime_add(tk->tkr_mono.base,
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH v5 3/6] timekeeping: Add clocksource to system_time_snapshot
2019-10-15 20:12 ` Thomas Gleixner
@ 2019-10-15 22:35 ` Paolo Bonzini
2019-10-16 10:01 ` Jianyong Wu (Arm Technology China)
1 sibling, 0 replies; 30+ messages in thread
From: Paolo Bonzini @ 2019-10-15 22:35 UTC (permalink / raw)
To: Thomas Gleixner, Jianyong Wu
Cc: justin.he, kvm, maz, richardcochran, yangbo.lu, linux-kernel,
sean.j.christopherson, john.stultz, netdev, nd, will, kvmarm,
linux-arm-kernel
On 15/10/19 22:12, Thomas Gleixner wrote:
> @@ -91,6 +96,7 @@ struct clocksource {
> const char *name;
> struct list_head list;
> int rating;
> + enum clocksource_ids id;
Why add a global id? ARM can add it to archdata similar to how x86 has
vclock_mode. But I still think the right thing to do is to include the
full system_counterval_t in the result of ktime_get_snapshot. (More in
a second, feel free to reply to the other email only).
Paolo
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* RE: [PATCH v5 3/6] timekeeping: Add clocksource to system_time_snapshot
2019-10-15 20:12 ` Thomas Gleixner
2019-10-15 22:35 ` Paolo Bonzini
@ 2019-10-16 10:01 ` Jianyong Wu (Arm Technology China)
2019-10-16 10:26 ` Thomas Gleixner
1 sibling, 1 reply; 30+ messages in thread
From: Jianyong Wu (Arm Technology China) @ 2019-10-16 10:01 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Justin He (Arm Technology China),
kvm, maz, richardcochran, yangbo.lu, linux-kernel,
sean.j.christopherson, john.stultz, netdev, pbonzini, nd, will,
kvmarm, linux-arm-kernel
Hi tglx,
> -----Original Message-----
> From: Thomas Gleixner <tglx@linutronix.de>
> Sent: Wednesday, October 16, 2019 4:13 AM
> To: Jianyong Wu (Arm Technology China) <Jianyong.Wu@arm.com>
> Cc: netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org;
> pbonzini@redhat.com; sean.j.christopherson@intel.com; maz@kernel.org;
> richardcochran@gmail.com; Mark Rutland <Mark.Rutland@arm.com>;
> will@kernel.org; Suzuki Poulose <Suzuki.Poulose@arm.com>; linux-
> kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org; Steve Capper
> <Steve.Capper@arm.com>; Kaly Xin (Arm Technology China)
> <Kaly.Xin@arm.com>; Justin He (Arm Technology China)
> <Justin.He@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v5 3/6] timekeeping: Add clocksource to
> system_time_snapshot
>
> On Tue, 15 Oct 2019, Jianyong Wu wrote:
>
> > Sometimes, we need check current clocksource outside of timekeeping
> > area. Add clocksource to system_time_snapshot then we can get
> > clocksource as well as system time.
>
> This changelog is telling absolutely nothing WHY anything outside of the
> timekeeping core code needs access to the current clocksource. Neither
> does it tell why it is safe to provide the pointer to random callers.
>
Really need more information.
> > +/*
> > + * struct system_time_snapshot - simultaneous raw/real time capture
> with
> > + * counter value
> > + * @sc: Contains clocksource and clocksource counter value
> to produce
> > + * the system times
> > + * @real: Realtime system time
> > + * @raw: Monotonic raw system time
> > + * @clock_was_set_seq: The sequence number of clock was set
> events
> > + * @cs_was_changed_seq: The sequence number of clocksource change
> events
> > + */
> > +struct system_time_snapshot {
> > + struct system_counterval_t sc;
> > + ktime_t real;
> > + ktime_t raw;
> > + unsigned int clock_was_set_seq;
> > + u8 cs_was_changed_seq;
> > +};
> > +
> > /*
> > * Get cross timestamp between system clock and device clock
> > */
> > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> > index 44b726bab4bd..66ff089605b3 100644
> > --- a/kernel/time/timekeeping.c
> > +++ b/kernel/time/timekeeping.c
> > @@ -983,7 +983,8 @@ void ktime_get_snapshot(struct
> system_time_snapshot *systime_snapshot)
> > nsec_raw = timekeeping_cycles_to_ns(&tk->tkr_raw, now);
> > } while (read_seqcount_retry(&tk_core.seq, seq));
> >
> > - systime_snapshot->cycles = now;
> > + systime_snapshot->sc.cycles = now;
> > + systime_snapshot->sc.cs = tk->tkr_mono.clock;
>
> The clock pointer can change right after the store, the underlying data can be
> freed .....
>
Yeah, need put it into seqcount region.
> Looking at the rest of the patch set the actual usage site is:
>
> > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > + ktime_get_snapshot(&systime_snapshot);
> > + if (!is_arm_arch_counter(systime_snapshot.sc.cs))
> > + return kvm_psci_call(vcpu);
>
> and that function does:
>
> > +bool is_arm_arch_counter(void *cs)
>
> void *? Type safety is overrated, right? The type is well known....
>
> +{
> + return (struct clocksource *)cs == &clocksource_counter;
>
> That nonsensical typecast does not make up for that.
>
It's really bad code and need fix.
> +}
>
> So while the access to the pointer is actually safe, this is not going to happen
> simply because you modify a generic interface in a way which will lead the
> next developer to insane assumptions about the validity of that pointer.
>
> While the kernel is pretty lax in terms of isolation due to the nature of the
> programming language, this does not justify to expose critical internals of
> core code to random callers. Guess why most of the timekeeping internals
> are carefully shielded from external access.
>
> Something like the completely untested (not even compiled) patch below
> gives you access to the information you need and allows to reuse the
> mechanism for other purposes without adding is_$FOO_timer() all over the
> place.
>
> Thanks,
>
> tglx
>
> 8<--------------
> --- a/include/linux/clocksource.h
> +++ b/include/linux/clocksource.h
> @@ -9,6 +9,7 @@
> #ifndef _LINUX_CLOCKSOURCE_H
> #define _LINUX_CLOCKSOURCE_H
>
> +#include <linux/clocksource_ids.h>
> #include <linux/types.h>
> #include <linux/timex.h>
> #include <linux/time.h>
> @@ -49,6 +50,10 @@ struct module;
> * 400-499: Perfect
> * The ideal clocksource. A must-use where
> * available.
> + * @id: Defaults to CSID_GENERIC. The id value is
> captured
> + * in certain snapshot functions to allow callers to
> + * validate the clocksource from which the snapshot
> was
> + * taken.
> * @read: returns a cycle value, passes clocksource as argument
> * @enable: optional function to enable the clocksource
> * @disable: optional function to disable the clocksource
> @@ -91,6 +96,7 @@ struct clocksource {
> const char *name;
> struct list_head list;
> int rating;
> + enum clocksource_ids id;
> int (*enable)(struct clocksource *cs);
> void (*disable)(struct clocksource *cs);
> unsigned long flags;
> --- /dev/null
> +++ b/include/linux/clocksource_ids.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_CLOCKSOURCE_IDS_H
> +#define _LINUX_CLOCKSOURCE_IDS_H
> +
> +/* Enum to give clocksources a unique identifier */ enum
> +clocksource_ids {
> + CSID_GENERIC = 0,
> + CSID_ARM_ARCH_COUNTER,
> + CSID_MAX,
> +};
> +
Does this mean I must add clocksource id for all kinds of ARCHs and update all the code which have checked clocksource in the old way?
Thanks
Jianyong
> +#endif
> --- a/include/linux/timekeeping.h
> +++ b/include/linux/timekeeping.h
> @@ -2,6 +2,7 @@
> #ifndef _LINUX_TIMEKEEPING_H
> #define _LINUX_TIMEKEEPING_H
>
> +#include <linux/clocksource_ids.h>
> #include <linux/errno.h>
>
> /* Included from linux/ktime.h */
> @@ -228,15 +229,17 @@ extern void timekeeping_inject_sleeptime
> * @cycles: Clocksource counter value to produce the system times
> * @real: Realtime system time
> * @raw: Monotonic raw system time
> + * @cs_id: The id of the current clocksource which produced the
> snapshot
> * @clock_was_set_seq: The sequence number of clock was set
> events
> * @cs_was_changed_seq: The sequence number of clocksource change
> events
> */
> struct system_time_snapshot {
> - u64 cycles;
> - ktime_t real;
> - ktime_t raw;
> - unsigned int clock_was_set_seq;
> - u8 cs_was_changed_seq;
> + u64 cycles;
> + ktime_t real;
> + ktime_t raw;
> + enum clocksource_ids cs_id;
> + unsigned int clock_was_set_seq;
> + u8 cs_was_changed_seq;
> };
>
> /*
> --- a/kernel/time/clocksource.c
> +++ b/kernel/time/clocksource.c
> @@ -921,6 +921,9 @@ int __clocksource_register_scale(struct
>
> clocksource_arch_init(cs);
>
> + if (WARN_ON_ONCE((unsigned int)cs->id >= CSID_MAX))
> + cs->id = CSID_GENERIC;
> +
> /* Initialize mult/shift and max_idle_ns */
> __clocksource_update_freq_scale(cs, scale, freq);
>
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -979,6 +979,7 @@ void ktime_get_snapshot(struct system_ti
> do {
> seq = read_seqcount_begin(&tk_core.seq);
> now = tk_clock_read(&tk->tkr_mono);
> + systime_snapshot->cs_id = tk->tkr_mono.clock->id;
> systime_snapshot->cs_was_changed_seq = tk-
> >cs_was_changed_seq;
> systime_snapshot->clock_was_set_seq = tk-
> >clock_was_set_seq;
> base_real = ktime_add(tk->tkr_mono.base,
>
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* RE: [PATCH v5 3/6] timekeeping: Add clocksource to system_time_snapshot
2019-10-16 10:01 ` Jianyong Wu (Arm Technology China)
@ 2019-10-16 10:26 ` Thomas Gleixner
0 siblings, 0 replies; 30+ messages in thread
From: Thomas Gleixner @ 2019-10-16 10:26 UTC (permalink / raw)
To: Jianyong Wu (Arm Technology China)
Cc: Justin He (Arm Technology China),
kvm, maz, richardcochran, yangbo.lu, linux-kernel,
sean.j.christopherson, john.stultz, netdev, pbonzini, nd, will,
kvmarm, linux-arm-kernel
On Wed, 16 Oct 2019, Jianyong Wu (Arm Technology China) wrote:
> On Wed, 16 Oct 2019, Thomas Gleixner wrote:
> > On Tue, 15 Oct 2019, Jianyong Wu wrote:
> > +/* Enum to give clocksources a unique identifier */ enum
> > +clocksource_ids {
> > + CSID_GENERIC = 0,
> > + CSID_ARM_ARCH_COUNTER,
> > + CSID_MAX,
> > +};
> > +
>
> Does this mean I must add clocksource id for all kinds of ARCHs and
> update all the code which have checked clocksource in the old way?
What is the old way? No code exists which can access the current
clocksource pointer because the core code does not expose it at all.
Thanks,
tglx
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v5 4/6] psci: Add hvc call service for ptp_kvm.
2019-10-15 10:48 [RFC PATCH v5 0/6] Enable ptp_kvm for arm64 Jianyong Wu
` (2 preceding siblings ...)
2019-10-15 10:48 ` [PATCH v5 3/6] timekeeping: Add clocksource to system_time_snapshot Jianyong Wu
@ 2019-10-15 10:48 ` Jianyong Wu
2019-10-16 7:24 ` Paolo Bonzini
2019-10-15 10:48 ` [PATCH v5 5/6] ptp: arm64: Enable ptp_kvm for arm64 Jianyong Wu
2019-10-15 10:48 ` [PATCH v5 6/6] kvm: arm64: Add capability check extension for ptp_kvm Jianyong Wu
5 siblings, 1 reply; 30+ messages in thread
From: Jianyong Wu @ 2019-10-15 10:48 UTC (permalink / raw)
To: netdev, yangbo.lu, john.stultz, tglx, pbonzini,
sean.j.christopherson, maz, richardcochran, Mark.Rutland, will,
suzuki.poulose
Cc: justin.he, kvm, jianyong.wu, linux-kernel, nd, kvmarm, linux-arm-kernel
This patch is the base of ptp_kvm for arm64.
ptp_kvm modules will call hvc to get this service.
The service offers real time and counter cycle of host for guest.
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
---
drivers/clocksource/arm_arch_timer.c | 5 +++++
include/clocksource/arm_arch_timer.h | 5 +++++
include/linux/arm-smccc.h | 12 ++++++++++++
virt/kvm/arm/psci.c | 21 +++++++++++++++++++++
4 files changed, 43 insertions(+)
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 07e57a49d1e8..3597f1f27b10 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -1634,3 +1634,8 @@ 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
+
+bool is_arm_arch_counter(void *cs)
+{
+ return (struct clocksource *)cs == &clocksource_counter;
+}
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index 1d68d5613dae..5895d10a6148 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -86,6 +86,7 @@ extern u32 arch_timer_get_rate(void);
extern u64 (*arch_timer_read_counter)(void);
extern struct arch_timer_kvm_info *arch_timer_get_kvm_info(void);
extern bool arch_timer_evtstrm_available(void);
+extern bool is_arm_arch_counter(void *);
#else
@@ -104,6 +105,10 @@ static inline bool arch_timer_evtstrm_available(void)
return false;
}
+bool is_arm_arch_counter(void *unuse)
+{
+ return false;
+}
#endif
#endif
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index a6e4d3e3d10a..bc0cdad10f35 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -94,6 +94,7 @@
/* KVM "vendor specific" services */
#define ARM_SMCCC_KVM_FUNC_FEATURES 0
+#define ARM_SMCCC_KVM_PTP 1
#define ARM_SMCCC_KVM_FUNC_FEATURES_2 127
#define ARM_SMCCC_KVM_NUM_FUNCS 128
@@ -103,6 +104,17 @@
ARM_SMCCC_OWNER_VENDOR_HYP, \
ARM_SMCCC_KVM_FUNC_FEATURES)
+/*
+ * This ID used for virtual ptp kvm clock and it will pass second value
+ * and nanosecond value of host real time and system counter by vcpu
+ * register to guest.
+ */
+#define ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_VENDOR_HYP, \
+ ARM_SMCCC_KVM_PTP)
+
#ifndef __ASSEMBLY__
#include <linux/linkage.h>
diff --git a/virt/kvm/arm/psci.c b/virt/kvm/arm/psci.c
index 0debf49bf259..f0ef388ebbfa 100644
--- a/virt/kvm/arm/psci.c
+++ b/virt/kvm/arm/psci.c
@@ -392,6 +392,8 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
u32 func_id = smccc_get_function(vcpu);
u32 val[4] = {};
u32 option;
+ u64 cycles;
+ struct system_time_snapshot systime_snapshot;
val[0] = SMCCC_RET_NOT_SUPPORTED;
@@ -431,6 +433,25 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
break;
+ /*
+ * This will used for virtual ptp kvm clock. three
+ * values will be passed back.
+ * reg0 stores high 32-bit host ktime;
+ * reg1 stores low 32-bit host ktime;
+ * reg2 stores high 32-bit difference of host cycles and cntvoff;
+ * reg3 stores low 32-bit difference of host cycles and cntvoff.
+ */
+ case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
+ ktime_get_snapshot(&systime_snapshot);
+ if (!is_arm_arch_counter(systime_snapshot.sc.cs))
+ return kvm_psci_call(vcpu);
+ val[0] = systime_snapshot.real >> 32;
+ val[1] = systime_snapshot.real << 32 >> 32;
+ cycles = systime_snapshot.sc.cycles -
+ vcpu_vtimer(vcpu)->cntvoff;
+ val[2] = cycles >> 32;
+ val[3] = cycles << 32 >> 32;
+ break;
default:
return kvm_psci_call(vcpu);
}
--
2.17.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH v5 4/6] psci: Add hvc call service for ptp_kvm.
2019-10-15 10:48 ` [PATCH v5 4/6] psci: Add hvc call service for ptp_kvm Jianyong Wu
@ 2019-10-16 7:24 ` Paolo Bonzini
2019-10-16 7:31 ` Thomas Gleixner
2019-10-16 10:20 ` Jianyong Wu (Arm Technology China)
0 siblings, 2 replies; 30+ messages in thread
From: Paolo Bonzini @ 2019-10-16 7:24 UTC (permalink / raw)
To: Jianyong Wu, netdev, yangbo.lu, john.stultz, tglx,
sean.j.christopherson, maz, richardcochran, Mark.Rutland, will,
suzuki.poulose
Cc: justin.he, kvm, linux-kernel, nd, kvmarm, linux-arm-kernel
On 15/10/19 12:48, Jianyong Wu wrote:
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 07e57a49d1e8..3597f1f27b10 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -1634,3 +1634,8 @@ 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
> +
> +bool is_arm_arch_counter(void *cs)
> +{
> + return (struct clocksource *)cs == &clocksource_counter;
> +}
As Thomas pointed out, any reason to have a void * here?
However, since he didn't like modifying the struct, here is an
alternative idea:
1) add a "struct clocksource*" argument to ktime_get_snapshot
2) return -ENODEV if the argument is not NULL and is not the current
clocksource
3) move the implementation of the hypercall to
drivers/clocksource/arm_arch_timer.c, so that it can call
ktime_get_snapshot(&systime_snapshot, &clocksource_counter);
Paolo
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH v5 4/6] psci: Add hvc call service for ptp_kvm.
2019-10-16 7:24 ` Paolo Bonzini
@ 2019-10-16 7:31 ` Thomas Gleixner
2019-10-16 7:42 ` Paolo Bonzini
2019-10-16 10:20 ` Jianyong Wu (Arm Technology China)
1 sibling, 1 reply; 30+ messages in thread
From: Thomas Gleixner @ 2019-10-16 7:31 UTC (permalink / raw)
To: Paolo Bonzini
Cc: justin.he, kvm, maz, richardcochran, Jianyong Wu, linux-kernel,
sean.j.christopherson, yangbo.lu, john.stultz, netdev, nd, will,
kvmarm, linux-arm-kernel
On Wed, 16 Oct 2019, Paolo Bonzini wrote:
> On 15/10/19 12:48, Jianyong Wu wrote:
> > diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> > index 07e57a49d1e8..3597f1f27b10 100644
> > --- a/drivers/clocksource/arm_arch_timer.c
> > +++ b/drivers/clocksource/arm_arch_timer.c
> > @@ -1634,3 +1634,8 @@ 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
> > +
> > +bool is_arm_arch_counter(void *cs)
> > +{
> > + return (struct clocksource *)cs == &clocksource_counter;
> > +}
>
> As Thomas pointed out, any reason to have a void * here?
>
> However, since he didn't like modifying the struct, here is an
> alternative idea:
>
> 1) add a "struct clocksource*" argument to ktime_get_snapshot
>
> 2) return -ENODEV if the argument is not NULL and is not the current
> clocksource
>
> 3) move the implementation of the hypercall to
> drivers/clocksource/arm_arch_timer.c, so that it can call
> ktime_get_snapshot(&systime_snapshot, &clocksource_counter);
And then you implement a gazillion of those functions for every
arch/subarch which has a similar requirement. Pointless exercise.
Having the ID is trivial enough and the storage space is not really a
concern.
Thanks,
tglx
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH v5 4/6] psci: Add hvc call service for ptp_kvm.
2019-10-16 7:31 ` Thomas Gleixner
@ 2019-10-16 7:42 ` Paolo Bonzini
0 siblings, 0 replies; 30+ messages in thread
From: Paolo Bonzini @ 2019-10-16 7:42 UTC (permalink / raw)
To: Thomas Gleixner
Cc: justin.he, kvm, maz, richardcochran, Jianyong Wu, linux-kernel,
sean.j.christopherson, yangbo.lu, john.stultz, netdev, nd, will,
kvmarm, linux-arm-kernel
On 16/10/19 09:31, Thomas Gleixner wrote:
>> 3) move the implementation of the hypercall to
>> drivers/clocksource/arm_arch_timer.c, so that it can call
>> ktime_get_snapshot(&systime_snapshot, &clocksource_counter);
>
> And then you implement a gazillion of those functions for every
> arch/subarch which has a similar requirement. Pointless exercise.
>
> Having the ID is trivial enough and the storage space is not really a
> concern.
Ok, good.
Paolo
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v5 4/6] psci: Add hvc call service for ptp_kvm.
2019-10-16 7:24 ` Paolo Bonzini
2019-10-16 7:31 ` Thomas Gleixner
@ 2019-10-16 10:20 ` Jianyong Wu (Arm Technology China)
1 sibling, 0 replies; 30+ messages in thread
From: Jianyong Wu (Arm Technology China) @ 2019-10-16 10:20 UTC (permalink / raw)
To: Paolo Bonzini, netdev, yangbo.lu, john.stultz, tglx,
sean.j.christopherson, maz, richardcochran, Mark Rutland, will,
Suzuki Poulose
Cc: Justin He (Arm Technology China),
kvm, linux-kernel, nd, kvmarm, linux-arm-kernel
Hi Paolo,
> -----Original Message-----
> From: Paolo Bonzini <pbonzini@redhat.com>
> Sent: Wednesday, October 16, 2019 3:25 PM
> To: Jianyong Wu (Arm Technology China) <Jianyong.Wu@arm.com>;
> netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org;
> tglx@linutronix.de; sean.j.christopherson@intel.com; maz@kernel.org;
> richardcochran@gmail.com; Mark Rutland <Mark.Rutland@arm.com>;
> will@kernel.org; Suzuki Poulose <Suzuki.Poulose@arm.com>
> Cc: linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org; Steve Capper
> <Steve.Capper@arm.com>; Kaly Xin (Arm Technology China)
> <Kaly.Xin@arm.com>; Justin He (Arm Technology China)
> <Justin.He@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v5 4/6] psci: Add hvc call service for ptp_kvm.
>
> On 15/10/19 12:48, Jianyong Wu wrote:
> > diff --git a/drivers/clocksource/arm_arch_timer.c
> > b/drivers/clocksource/arm_arch_timer.c
> > index 07e57a49d1e8..3597f1f27b10 100644
> > --- a/drivers/clocksource/arm_arch_timer.c
> > +++ b/drivers/clocksource/arm_arch_timer.c
> > @@ -1634,3 +1634,8 @@ 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
> > +
> > +bool is_arm_arch_counter(void *cs)
> > +{
> > + return (struct clocksource *)cs == &clocksource_counter; }
>
> As Thomas pointed out, any reason to have a void * here?
Need fix.
Thanks
Jianyong
>
> However, since he didn't like modifying the struct, here is an alternative idea:
>
> 1) add a "struct clocksource*" argument to ktime_get_snapshot
>
> 2) return -ENODEV if the argument is not NULL and is not the current
> clocksource
>
> 3) move the implementation of the hypercall to
> drivers/clocksource/arm_arch_timer.c, so that it can call
> ktime_get_snapshot(&systime_snapshot, &clocksource_counter);
>
> Paolo
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v5 5/6] ptp: arm64: Enable ptp_kvm for arm64
2019-10-15 10:48 [RFC PATCH v5 0/6] Enable ptp_kvm for arm64 Jianyong Wu
` (3 preceding siblings ...)
2019-10-15 10:48 ` [PATCH v5 4/6] psci: Add hvc call service for ptp_kvm Jianyong Wu
@ 2019-10-15 10:48 ` Jianyong Wu
2019-10-15 16:39 ` Paolo Bonzini
2019-10-15 10:48 ` [PATCH v5 6/6] kvm: arm64: Add capability check extension for ptp_kvm Jianyong Wu
5 siblings, 1 reply; 30+ messages in thread
From: Jianyong Wu @ 2019-10-15 10:48 UTC (permalink / raw)
To: netdev, yangbo.lu, john.stultz, tglx, pbonzini,
sean.j.christopherson, maz, richardcochran, Mark.Rutland, will,
suzuki.poulose
Cc: justin.he, kvm, jianyong.wu, linux-kernel, nd, kvmarm, linux-arm-kernel
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 | 54 ++++++++++++++++++++++++++++
drivers/ptp/ptp_kvm_common.c | 2 +-
4 files changed, 78 insertions(+), 2 deletions(-)
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 3597f1f27b10..3e1fd794451f 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -1639,3 +1639,25 @@ bool is_arm_arch_counter(void *cs)
{
return (struct clocksource *)cs == &clocksource_counter;
}
+
+#if IS_ENABLED(CONFIG_PTP_1588_CLOCK_KVM)
+#include <linux/arm-smccc.h>
+int kvm_arch_ptp_get_clock_fn(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;
+ *cs = &clocksource_counter;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(kvm_arch_ptp_get_clock_fn);
+#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..7c697f20904f
--- /dev/null
+++ b/drivers/ptp/ptp_kvm_arm64.c
@@ -0,0 +1,54 @@
+// 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)
+{
+ u64 ns;
+ 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;
+}
diff --git a/drivers/ptp/ptp_kvm_common.c b/drivers/ptp/ptp_kvm_common.c
index d8f215186904..c0b445fa6144 100644
--- a/drivers/ptp/ptp_kvm_common.c
+++ b/drivers/ptp/ptp_kvm_common.c
@@ -138,7 +138,7 @@ static int __init ptp_kvm_init(void)
int ret;
ret = kvm_arch_ptp_init();
- if (!ret)
+ if (ret)
return -EOPNOTSUPP;
kvm_ptp_clock.caps = ptp_kvm_caps;
--
2.17.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH v5 5/6] ptp: arm64: Enable ptp_kvm for arm64
2019-10-15 10:48 ` [PATCH v5 5/6] ptp: arm64: Enable ptp_kvm for arm64 Jianyong Wu
@ 2019-10-15 16:39 ` Paolo Bonzini
2019-10-16 3:52 ` Jianyong Wu (Arm Technology China)
0 siblings, 1 reply; 30+ messages in thread
From: Paolo Bonzini @ 2019-10-15 16:39 UTC (permalink / raw)
To: Jianyong Wu, netdev, yangbo.lu, john.stultz, tglx,
sean.j.christopherson, maz, richardcochran, Mark.Rutland, will,
suzuki.poulose
Cc: justin.he, kvm, linux-kernel, nd, kvmarm, linux-arm-kernel
On 15/10/19 12:48, Jianyong Wu wrote:
> +int kvm_arch_ptp_get_clock_generic(struct timespec64 *ts,
> + struct arm_smccc_res *hvc_res)
> +{
> + u64 ns;
> + 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;
> +}
> +
This seems wrong, who uses kvm_arch_ptp_get_clock_fn?
Paolo
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* RE: [PATCH v5 5/6] ptp: arm64: Enable ptp_kvm for arm64
2019-10-15 16:39 ` Paolo Bonzini
@ 2019-10-16 3:52 ` Jianyong Wu (Arm Technology China)
2019-10-16 7:10 ` Paolo Bonzini
0 siblings, 1 reply; 30+ messages in thread
From: Jianyong Wu (Arm Technology China) @ 2019-10-16 3:52 UTC (permalink / raw)
To: Paolo Bonzini, netdev, yangbo.lu, john.stultz, tglx,
sean.j.christopherson, maz, richardcochran, Mark Rutland, will,
Suzuki Poulose
Cc: Justin He (Arm Technology China),
kvm, linux-kernel, nd, kvmarm, linux-arm-kernel
Hi Paolo,
> -----Original Message-----
> From: Paolo Bonzini <pbonzini@redhat.com>
> Sent: Wednesday, October 16, 2019 12:39 AM
> To: Jianyong Wu (Arm Technology China) <Jianyong.Wu@arm.com>;
> netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org;
> tglx@linutronix.de; sean.j.christopherson@intel.com; maz@kernel.org;
> richardcochran@gmail.com; Mark Rutland <Mark.Rutland@arm.com>;
> will@kernel.org; Suzuki Poulose <Suzuki.Poulose@arm.com>
> Cc: linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org; Steve Capper
> <Steve.Capper@arm.com>; Kaly Xin (Arm Technology China)
> <Kaly.Xin@arm.com>; Justin He (Arm Technology China)
> <Justin.He@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v5 5/6] ptp: arm64: Enable ptp_kvm for arm64
>
> On 15/10/19 12:48, Jianyong Wu wrote:
> > +int kvm_arch_ptp_get_clock_generic(struct timespec64 *ts,
> > + struct arm_smccc_res *hvc_res) {
> > + u64 ns;
> > + ktime_t ktime_overall;
> > +
> > +
> arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FU
> NC_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;
> > +}
> > +
>
> This seems wrong, who uses kvm_arch_ptp_get_clock_fn?
>
This func used only by kvm_arch_ptp_get_clock and nothing to do with kvm_arch_ptp_get_clock_fn.
Also it can be merged into kvm_arch_ptp_get_clock.
> Paolo
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH v5 5/6] ptp: arm64: Enable ptp_kvm for arm64
2019-10-16 3:52 ` Jianyong Wu (Arm Technology China)
@ 2019-10-16 7:10 ` Paolo Bonzini
2019-10-16 7:13 ` Paolo Bonzini
0 siblings, 1 reply; 30+ messages in thread
From: Paolo Bonzini @ 2019-10-16 7:10 UTC (permalink / raw)
To: Jianyong Wu (Arm Technology China),
netdev, yangbo.lu, john.stultz, tglx, sean.j.christopherson, maz,
richardcochran, Mark Rutland, will, Suzuki Poulose
Cc: Justin He (Arm Technology China),
kvm, linux-kernel, nd, kvmarm, linux-arm-kernel
On 16/10/19 05:52, Jianyong Wu (Arm Technology China) wrote:
> This func used only by kvm_arch_ptp_get_clock and nothing to do with
> kvm_arch_ptp_get_clock_fn. Also it can be merged into
> kvm_arch_ptp_get_clock.
>
Your patches also have no user for kvm_arch_ptp_get_clock, so you can
remove it.
Paolo
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 5/6] ptp: arm64: Enable ptp_kvm for arm64
2019-10-16 7:10 ` Paolo Bonzini
@ 2019-10-16 7:13 ` Paolo Bonzini
2019-10-16 10:11 ` Jianyong Wu (Arm Technology China)
0 siblings, 1 reply; 30+ messages in thread
From: Paolo Bonzini @ 2019-10-16 7:13 UTC (permalink / raw)
To: Jianyong Wu (Arm Technology China),
netdev, yangbo.lu, john.stultz, tglx, sean.j.christopherson, maz,
richardcochran, Mark Rutland, will, Suzuki Poulose
Cc: Justin He (Arm Technology China),
kvm, linux-kernel, nd, kvmarm, linux-arm-kernel
On 16/10/19 09:10, Paolo Bonzini wrote:
> On 16/10/19 05:52, Jianyong Wu (Arm Technology China) wrote:
>> This func used only by kvm_arch_ptp_get_clock and nothing to do with
>> kvm_arch_ptp_get_clock_fn. Also it can be merged into
>> kvm_arch_ptp_get_clock.
>>
>
> Your patches also have no user for kvm_arch_ptp_get_clock, so you can
> remove it.
Nevermind. I misread patch 2. However, to remove the confusion, can
you rename kvm_arch_ptp_get_clock_fn to kvm_arch_ptp_get_crosststamp?
Paolo
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v5 5/6] ptp: arm64: Enable ptp_kvm for arm64
2019-10-16 7:13 ` Paolo Bonzini
@ 2019-10-16 10:11 ` Jianyong Wu (Arm Technology China)
0 siblings, 0 replies; 30+ messages in thread
From: Jianyong Wu (Arm Technology China) @ 2019-10-16 10:11 UTC (permalink / raw)
To: Paolo Bonzini, netdev, yangbo.lu, john.stultz, tglx,
sean.j.christopherson, maz, richardcochran, Mark Rutland, will,
Suzuki Poulose
Cc: Justin He (Arm Technology China),
kvm, linux-kernel, nd, kvmarm, linux-arm-kernel
Hi Paolo,
> -----Original Message-----
> From: Paolo Bonzini <pbonzini@redhat.com>
> Sent: Wednesday, October 16, 2019 3:14 PM
> To: Jianyong Wu (Arm Technology China) <Jianyong.Wu@arm.com>;
> netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org;
> tglx@linutronix.de; sean.j.christopherson@intel.com; maz@kernel.org;
> richardcochran@gmail.com; Mark Rutland <Mark.Rutland@arm.com>;
> will@kernel.org; Suzuki Poulose <Suzuki.Poulose@arm.com>
> Cc: linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org; Steve Capper
> <Steve.Capper@arm.com>; Kaly Xin (Arm Technology China)
> <Kaly.Xin@arm.com>; Justin He (Arm Technology China)
> <Justin.He@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v5 5/6] ptp: arm64: Enable ptp_kvm for arm64
>
> On 16/10/19 09:10, Paolo Bonzini wrote:
> > On 16/10/19 05:52, Jianyong Wu (Arm Technology China) wrote:
> >> This func used only by kvm_arch_ptp_get_clock and nothing to do with
> >> kvm_arch_ptp_get_clock_fn. Also it can be merged into
> >> kvm_arch_ptp_get_clock.
> >>
> >
> > Your patches also have no user for kvm_arch_ptp_get_clock, so you can
> > remove it.
>
> Nevermind. I misread patch 2. However, to remove the confusion, can you
> rename kvm_arch_ptp_get_clock_fn to kvm_arch_ptp_get_crosststamp?
>
the suffix of this function name is reserved from its arch-independent caller ptp_kvm_get_time_fn, so if I change this function name
It will be better change them whole. I think "ptp_get_crosststamp" is a better suffix.
Thanks
Jianyong
> Paolo
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v5 6/6] kvm: arm64: Add capability check extension for ptp_kvm
2019-10-15 10:48 [RFC PATCH v5 0/6] Enable ptp_kvm for arm64 Jianyong Wu
` (4 preceding siblings ...)
2019-10-15 10:48 ` [PATCH v5 5/6] ptp: arm64: Enable ptp_kvm for arm64 Jianyong Wu
@ 2019-10-15 10:48 ` Jianyong Wu
5 siblings, 0 replies; 30+ messages in thread
From: Jianyong Wu @ 2019-10-15 10:48 UTC (permalink / raw)
To: netdev, yangbo.lu, john.stultz, tglx, pbonzini,
sean.j.christopherson, maz, richardcochran, Mark.Rutland, will,
suzuki.poulose
Cc: justin.he, kvm, jianyong.wu, linux-kernel, nd, kvmarm, linux-arm-kernel
Let userspace check if there is kvm ptp service in host.
before VMs migrate to a another host, VMM may check if this
cap is available to determine the migration behaviour.
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Suggested-by: Marc Zyngier <maz@kernel.org>
---
include/uapi/linux/kvm.h | 1 +
virt/kvm/arm/arm.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 2fe12b40d503..a0bff6002bd9 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -993,6 +993,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_ARM_SVE 170
#define KVM_CAP_ARM_PTRAUTH_ADDRESS 171
#define KVM_CAP_ARM_PTRAUTH_GENERIC 172
+#define KVM_CAP_ARM_KVM_PTP 173
#ifdef KVM_CAP_IRQ_ROUTING
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index bd5c55916d0d..80999985160b 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -201,6 +201,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_MP_STATE:
case KVM_CAP_IMMEDIATE_EXIT:
case KVM_CAP_VCPU_EVENTS:
+ case KVM_CAP_ARM_KVM_PTP:
r = 1;
break;
case KVM_CAP_ARM_SET_DEVICE_ADDR:
--
2.17.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 30+ messages in thread