[Xenomai-core] [PATCH 0/7] Host realtime clock support

[Xenomai-core] [PATCH 0/7] Host realtime clock support

[Wolfgang Mauerer]

(This is the Xenomai part of the mechanism, please see the ipipe
 mailing list for the patches that provide the required basis 
 infrastructure)

This patch series extends Xenomai with a new clock, CLOCK_HOST_REALTIME.
It allows for sharing NTP-corrected real time timestamps between
Linux/ipipe and Xenomai. The data are also available in userspace and can
be read without switching to kernel mode. Notice, however, that the new
clock only enables to read to time, but cannot serve as a full time basis.
Some changes to the ipipe layer are required as basis.

In contrast to the initial approach, we don't use a transactional mechanism
to copy the information over from Linux, but use classical synchronisation.
The code can be compiled in conditionally for both, ipipe and Xenomai. When
disabled by architectures that don't support apt clock sources, there is
no runtime-overhead associated with the feature.

Some points that may require further discussion:

- POSIX only specifies a few clock_ids, and these have already been
  extended by the Linux kernel. We use the maximum id (16) for the new
  clock, but it might also make sense to use 7 (CLOCK_MONOTONIC_COARSE+1)
  or 4 (CLOCK_THREAD_CPUTIME_ID+1).

- The current implementation deals with x86_64's TSC. Support for other
  architectures can be added. Additionally, the user has to make sure that
  the TSC clock source remains active once selected.  To implement 
  deactivation (e.g., when the Linux clock source is changed), more 
  ipipe hooks would be required, though.

  There are two alternatives including other architectures:

  * We can create a new clocksource that abstracts the per-architecture
    differences, and use this clocksource as basis for
    Xenomai. Essentially, this means mapping all desired
    non-x86-Clocksources to the interface offered in this patch.
    This requires more changes in the ipipe layer than variant B, namely,
  * We can create a union in struct xnvdso of all arch-specific clock
    datasets and introduce feature flags like XNVDSO_FEAT_HOSTRT_X86,
    XNVDSO_FEAT_HOSTRT_WHATEVER. The reader-side code then needs to
    match the data provided, which requires more changes on the
    Xenomai side.

- The series supports dynamic switching from a non-TSC clocksource to
  clocksource_tsc, but does not handle the other direction. This is
  intentional, because when a user wants meaningful synchronised time
  stamps, the reliability of the underlying clock should be ensured.

  Naturally, it would be possible to detect this change at the kernel
  level, but this would make the ipipe part more intrusive.

The code compiles with all combinations of IPIPE_HOSTRT and
OPT_XENO_HOSTRT.

As always, thanks for your comments and review!

Best, Wolfgang

---
 examples/posix/Makefile         |    3 -
 examples/posix/show_hrtime.c    |   82 ++++++++++++++++++++++++++++++++++++
 include/asm-generic/hal.h       |    2
 include/asm-generic/system.h    |    4 +
 include/asm-sim/system.h        |    4 +
 include/asm-x86/atomic.h        |    5 ++
 include/nucleus/Makefile.am     |    2
 include/nucleus/hostrt.h        |   65 ++++++++++++++++++++++++++++
 include/nucleus/seqlock_user.h  |   57 +++++++++++++++++++++++++
 include/nucleus/vdso.h          |   20 +++++++-
 include/posix/time.h            |    2
 ksrc/nucleus/Kconfig            |    4 +
 ksrc/nucleus/module.c           |   25 +++++++++++
 ksrc/skins/posix/clock.c        |   90 +++++++++++++++++++++++++++++++++++++++-
 src/skins/posix/clock.c         |   65 ++++++++++++++++++++++++++++
 src/testsuite/unit/check-vdso.c |    2
 16 files changed, 426 insertions(+), 6 deletions(-)

[Xenomai-core] [PATCH 1/7] nucleus: Spelling fix for check-vdso.c

[Wolfgang Mauerer]

Signed-off-by: Wolfgang Mauerer <wolfgang.mauerer@domain.hid>
Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
---
 src/testsuite/unit/check-vdso.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/testsuite/unit/check-vdso.c b/src/testsuite/unit/check-vdso.c
index 8f90420..17684de 100644
--- a/src/testsuite/unit/check-vdso.c
+++ b/src/testsuite/unit/check-vdso.c
@@ -15,7 +15,7 @@ int main(int argc, char **argv)
 	unsigned long long test_features;
 
 	if (argc != 2) {
-		printf("No specific feature(s) given, using XNVDSO_FEATURE\n");
+		printf("No specific feature(s) given, using XNVDSO_FEATURES\n");
 		test_features = XNVDSO_FEATURES;
 	} else {
 		test_features = strtoull(argv[1], NULL, 0);
-- 
1.6.4

[Xenomai-core] [PATCH 2/7] nucleus: Sanity check for vdso.h

[Wolfgang Mauerer]

Including the file only makes sense when support for pervasive
rt is enabled, so add a corresponding check.

Signed-off-by: Wolfgang Mauerer <wolfgang.mauerer@domain.hid>
Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
---
 include/nucleus/vdso.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/include/nucleus/vdso.h b/include/nucleus/vdso.h
index c431f88..2343e5d 100644
--- a/include/nucleus/vdso.h
+++ b/include/nucleus/vdso.h
@@ -23,6 +23,10 @@
  * 02111-1307, USA.
  */
 
+#if defined(__KERNEL__) && !defined(CONFIG_XENO_OPT_PERVASIVE)
+#error "vdso.h included in a kernel configuration without pervasive rt support!"
+#endif
+
 #include <nucleus/types.h>
 
 /*
-- 
1.6.4

[Xenomai-core] [PATCH 3/7] nucleus: Add userland cpu_relax() definition for x86

[Wolfgang Mauerer]

Signed-off-by: Wolfgang Mauerer <wolfgang.mauerer@domain.hid>
Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
---
 include/asm-x86/atomic.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/include/asm-x86/atomic.h b/include/asm-x86/atomic.h
index bb3ce46..16bc990 100644
--- a/include/asm-x86/atomic.h
+++ b/include/asm-x86/atomic.h
@@ -71,6 +71,11 @@ typedef struct { unsigned long counter; } xnarch_atomic_t;
 
 #define xnarch_write_memory_barrier()	xnarch_memory_barrier()
 
+static inline void cpu_relax(void)
+{
+	asm volatile("rep; nop" ::: "memory");
+}
+
 #ifdef __i386__
 
 struct __xeno_xchg_dummy { unsigned long a[100]; };
-- 
1.6.4

[Xenomai-core] [PATCH 4/7] nucleus: Add CLOCK_HOST_REALTIME bits to nkvdso

[Wolfgang Mauerer]

Augment the shared vdso page with all data required to
implement a clock CLOCK_HOST_REALTIME that provides time
information synchronised with the NTP-corrected time
in the Linux kernel.

The definition of the hostrt data is placed in a separate
head file so that we can use it irregardless of pervasive
rt support is compiled in or not.

Signed-off-by: Wolfgang Mauerer <wolfgang.mauerer@domain.hid>
Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
---
 include/asm-generic/hal.h    |    2 +
 include/asm-generic/system.h |    4 ++
 include/asm-sim/system.h     |    4 ++
 include/nucleus/Makefile.am  |    1 +
 include/nucleus/hostrt.h     |   65 ++++++++++++++++++++++++++++++++++++++++++
 include/nucleus/vdso.h       |   16 ++++++++--
 ksrc/nucleus/Kconfig         |    4 ++
 ksrc/nucleus/module.c        |   25 ++++++++++++++++
 8 files changed, 118 insertions(+), 3 deletions(-)
 create mode 100644 include/nucleus/hostrt.h

diff --git a/include/asm-generic/hal.h b/include/asm-generic/hal.h
index f90cafa..4203a3b 100644
--- a/include/asm-generic/hal.h
+++ b/include/asm-generic/hal.h
@@ -680,6 +680,8 @@ static inline int rthal_trace_panic_dump(void)
 
 #endif /* CONFIG_IPIPE_TRACE */
 
+#define rthal_set_hostrt_data	ipipe_set_hostrt_data
+#define rthal_hostrt_data	ipipe_hostrt_data
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
diff --git a/include/asm-generic/system.h b/include/asm-generic/system.h
index a2c8fb9..a4e278a 100644
--- a/include/asm-generic/system.h
+++ b/include/asm-generic/system.h
@@ -490,4 +490,8 @@ static inline void xnarch_hisyscall_entry(void)	{ }
 #define xnarch_post_graph(obj,state)
 #define xnarch_post_graph_if(obj,state,cond)
 
+/* Synchronised realtime clock*/
+#define xnarch_set_hostrt_data	rthal_set_hostrt_data
+#define xnarch_hostrt_data	rthal_hostrt_data
+
 #endif /* !_XENO_ASM_GENERIC_SYSTEM_H */
diff --git a/include/asm-sim/system.h b/include/asm-sim/system.h
index 1a5a875..56af408 100644
--- a/include/asm-sim/system.h
+++ b/include/asm-sim/system.h
@@ -598,4 +598,8 @@ static inline long IS_ERR(const void *ptr)
 	return IS_ERR_VALUE((unsigned long)ptr);
 }
 
+/* Host realtime support is not supported in the simulator */
+#define xnarch_set_hostrt_data	{ }
+struct xnarch_hostrt_data { };
+
 #endif /* !_XENO_ASM_SIM_SYSTEM_H */
diff --git a/include/nucleus/Makefile.am b/include/nucleus/Makefile.am
index 3a6a024..b04d7f6 100644
--- a/include/nucleus/Makefile.am
+++ b/include/nucleus/Makefile.am
@@ -6,6 +6,7 @@ includesub_HEADERS = \
 	bufd.h \
 	compiler.h \
 	heap.h \
+	hostrt.h \
 	intr.h \
 	jhash.h \
 	map.h \
diff --git a/include/nucleus/hostrt.h b/include/nucleus/hostrt.h
new file mode 100644
index 0000000..5230165
--- /dev/null
+++ b/include/nucleus/hostrt.h
@@ -0,0 +1,65 @@
+#ifndef _XENO_NUCLEUS_HOSTRT_H
+#define _XENO_NUCLEUS_HOSTRT_H
+
+/*!\file hostrt.h
+ * \brief Definitions for global semaphore heap shared objects
+ * \author Wolfgang Mauerer
+ *
+ * Copyright (C) 2010 Wolfgang Mauerer <wolfgang.mauerer@domain.hid>.
+ *
+ * Xenomai is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; either version 2 of the License,
+ * or (at your option) any later version.
+ *
+ * Xenomai is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with Xenomai; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+ * 02111-1307, USA.
+ */
+
+#include <nucleus/types.h>
+#ifdef __KERNEL__
+#include <linux/time.h>
+#include <linux/ipipe_tickdev.h>
+#include <asm-generic/xenomai/system.h>
+
+#ifndef CONFIG_XENO_OPT_PERVASIVE
+extern struct xnarch_hostrt_data *nkhostrt_data;
+
+static inline struct xnarch_hostrt_data *get_hostrt_data(void)
+{
+	return nkhostrt_data;
+}
+#endif /* !CONFIG_XENO_OPT_PERVASIVE */
+#else /* !__KERNEL__ */
+#include <time.h>
+#include <sys/types.h>
+#include <nucleus/seqlock_user.h>
+typedef u_int32_t u32;
+typedef u_int64_t cycle_t;
+
+/*
+ * xnarch_hostrt_data must be kept in sync with the corresponding ipipe
+ * definitions in ipipe_tickdev.h We cannot directly include the file
+ * here because the definitions are also required in Xenomai userland.
+ */
+struct xnarch_hostrt_data {
+	short live;
+	seqcount_t seqcount;
+	time_t wall_time_sec;
+	u32 wall_time_nsec;
+	struct timespec wall_to_monotonic;
+	cycle_t cycle_last;
+	cycle_t mask;
+	u32 mult;
+	u32 shift;
+};
+#endif /* !__KERNEL__ */
+
+#endif
diff --git a/include/nucleus/vdso.h b/include/nucleus/vdso.h
index 2343e5d..57f2ee7 100644
--- a/include/nucleus/vdso.h
+++ b/include/nucleus/vdso.h
@@ -28,6 +28,7 @@
 #endif
 
 #include <nucleus/types.h>
+#include <nucleus/hostrt.h>
 
 /*
  * Data shared between Xenomai kernel/userland and the Linux kernel/userland
@@ -37,8 +38,11 @@
 struct xnvdso {
 	unsigned long long features;
 
-	/* Embed domain specific structures that describe the
-	 * shared data here */
+	struct xnarch_hostrt_data hostrt_data;
+	/*
+	 * Embed further domain specific structures that
+	 * describe the shared data here
+	 */
 };
 
 /*
@@ -52,10 +56,16 @@ struct xnvdso {
 #define XNVDSO_FEATURES	(XNVDSO_FEAT_A | XNVDSO_FEAT_B | XVDSO_FEAT_C)
 */
 #define XNVDSO_FEAT_DROP_U_MODE 0x0000000000000001ULL
-#define XNVDSO_FEATURES (XNVDSO_FEAT_DROP_U_MODE)
+#define XNVDSO_FEAT_HOST_REALTIME	0x0000000000000002ULL
+#define XNVDSO_FEATURES (XNVDSO_FEAT_DROP_U_MODE | XNVDSO_FEAT_HOST_REALTIME)
 
 extern struct xnvdso *nkvdso;
 
+static inline struct xnarch_hostrt_data *get_hostrt_data(void)
+{
+	return &nkvdso->hostrt_data;
+}
+
 static inline int xnvdso_test_feature(unsigned long long feature)
 {
 	return testbits(nkvdso->features, feature);
diff --git a/ksrc/nucleus/Kconfig b/ksrc/nucleus/Kconfig
index 211a4ad..3724e68 100644
--- a/ksrc/nucleus/Kconfig
+++ b/ksrc/nucleus/Kconfig
@@ -355,6 +355,10 @@ config XENO_OPT_SHIRQ
 config XENO_OPT_SELECT
 	bool
 
+config XENO_OPT_HOSTRT
+       depends on IPIPE_HOSTRT
+       def_bool y
+
 menu "Timing"
 
 config XENO_OPT_TIMING_PERIODIC
diff --git a/ksrc/nucleus/module.c b/ksrc/nucleus/module.c
index 84cec06..8e5ad40 100644
--- a/ksrc/nucleus/module.c
+++ b/ksrc/nucleus/module.c
@@ -35,12 +35,28 @@
 #endif /* CONFIG_XENO_OPT_PIPE */
 #include <nucleus/select.h>
 #include <asm/xenomai/bits/init.h>
+
 #ifdef CONFIG_XENO_OPT_PERVASIVE
 #include <nucleus/vdso.h>
 #else
 static inline void xnheap_init_vdso(void) { }
 #endif /* CONFIG_XENO_OPT_PERVASIVE */
 
+#ifdef CONFIG_XENO_OPT_HOSTRT
+#include <nucleus/hostrt.h>
+
+#ifndef CONFIG_XENO_OPT_PERVASIVE
+struct xnarch_hostrt_data *nkhostrt_data;
+#endif
+
+static inline void init_hostrt(void)
+{
+	seqcount_init(&get_hostrt_data()->seqcount);
+	xnarch_set_hostrt_data(get_hostrt_data());
+}
+#else
+static inline void init_hostrt(void) { }
+#endif /* CONFIG_XENO_OPT_HOSTRT */
 MODULE_DESCRIPTION("Xenomai nucleus");
 MODULE_AUTHOR("rpm@xenomai.org");
 MODULE_LICENSE("GPL");
@@ -113,7 +129,16 @@ int __init __xeno_sys_init(void)
 	xnheap_set_label(&__xnsys_global_ppd.sem_heap, "global sem heap");
 
 	xnheap_init_vdso();
+
+#if defined(CONFIG_XENO_OPT_HOSTRT) && !defined(CONFIG_XENO_OPT_PERVASIVE)
+	nkhostrt_data = xnarch_alloc_host_mem(sizeof(struct xnarch_hostrt_data));
+	if (nkhostrt_data == NULL) {
+		ret = -ENOMEM;
+		goto fail;
+	}
 #endif
+	init_hostrt();
+#endif /* !__XENO_SIM__ */
 	
 #ifdef __KERNEL__
 	xnpod_mount();
-- 
1.6.4

[Xenomai-core] [PATCH 5/7] posix: Support reading the host realtime clock in realtime context

[Wolfgang Mauerer]

Wall time management is typically assisted by the NTP
protocol in the Linux context, but this information is
not propagated to Xenomai. This patch adds support
for a CLOCK_HOST_REALTIME clock id that is coupled to the
host operating system's realtime clock. The required
information from the Kernel into Xenomai. The data exchange
is designed to allow for lockless reading from userland.

Signed-off-by: Wolfgang Mauerer <wolfgang.mauerer@domain.hid>
Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
---
 include/posix/time.h     |    2 +
 ksrc/skins/posix/clock.c |   90 +++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 91 insertions(+), 1 deletions(-)

diff --git a/include/posix/time.h b/include/posix/time.h
index 4f2d760..938feb6 100644
--- a/include/posix/time.h
+++ b/include/posix/time.h
@@ -50,6 +50,8 @@
 #define CLOCK_MONOTONIC 1
 #endif /* CLOCK_MONOTONIC */
 
+#define CLOCK_HOST_REALTIME 16
+
 #if defined(__KERNEL__) || defined(__XENO_SIM__)
 
 struct sigevent;
diff --git a/ksrc/skins/posix/clock.c b/ksrc/skins/posix/clock.c
index 553e123..f5a789b 100644
--- a/ksrc/skins/posix/clock.c
+++ b/ksrc/skins/posix/clock.c
@@ -50,6 +50,13 @@
  *@{*/
 
 #include <posix/thread.h>
+#include <linux/ipipe_tickdev.h>
+#include <linux/math64.h>
+#include <nucleus/hostrt.h>
+#ifdef CONFIG_XENO_OPT_PERVASIVE
+#include <nucleus/vdso.h>
+#endif
+#include <asm-generic/xenomai/system.h>
 
 /**
  * Get the resolution of the specified clock.
@@ -88,6 +95,76 @@ int clock_getres(clockid_t clock_id, struct timespec *res)
 }
 
 /**
+ * Read the host-synchronised realtime clock.
+ *
+ * Obtain the current time with NTP corrections from the Linux domain
+ *
+ * @param tp pointer to a struct timespec
+ *
+ * @retval 0 on success;
+ * @retval -1 if no suitable NTP-corrected clocksource is availabel
+ *
+ * @see
+ * <a href="http://www.opengroup.org/onlinepubs/000095399/functions/gettimeofday.html">
+ * Specification.</a>
+ *
+ */
+static int do_clock_host_realtime(struct timespec *tp)
+{
+#ifdef CONFIG_XENO_OPT_HOSTRT
+	cycle_t now, base, mask, cycle_delta;
+	unsigned long mult, shift, nsec, rem;
+	struct xnarch_hostrt_data *hostrt_data;
+	unsigned int seq;
+
+	hostrt_data = get_hostrt_data();
+	BUG_ON(!hostrt_data);
+
+	if (unlikely(!hostrt_data->live))
+		return -1;
+
+	/*
+	 * Note: Disabling HW interrupts around writes to hostrt_data ensures
+	 * that a reader (on the Xenomai side) cannot interrupt a writer (on
+	 * the Linux kernel side) on the same CPU.  The sequence counter is
+	 * required when a reader is interleaved by a writer on a different
+	 * CPU. This follows the approach from userland, where tasking the
+	 * spinlock is not possible.
+	 */
+retry:
+	seq = read_seqcount_begin(&hostrt_data->seqcount);
+
+	now = xnarch_get_cpu_tsc();
+	base = hostrt_data->cycle_last;
+	mask = hostrt_data->mask;
+	mult = hostrt_data->mult;
+	shift = hostrt_data->shift;
+	tp->tv_sec = hostrt_data->wall_time_sec;
+	nsec = hostrt_data->wall_time_nsec;
+
+	if (read_seqcount_retry(&hostrt_data->seqcount, seq))
+		goto retry;
+
+	/*
+	 * At this point, we have a consistent copy of the fundamental
+	 * data structure - calculate the interval between the current
+	 * and base time stamp cycles, and convert the difference
+	 * to nanoseconds.
+	 */
+	cycle_delta = (now - base) & mask;
+	nsec += (cycle_delta * mult) >> shift;
+
+	/* Convert to the desired sec, usec representation */
+	tp->tv_sec += xnarch_divrem_billion(nsec, &rem);
+	tp->tv_nsec = rem;
+
+	return 0;
+#else /* CONFIG_XENO_OPT_HOSTRT */
+	return -1;
+#endif
+}
+
+/**
  * Read the specified clock. 
  *
  * This service returns, at the address @a tp the current value of the clock @a
@@ -97,8 +174,12 @@ int clock_getres(clockid_t clock_id, struct timespec *res)
  * - CLOCK_MONOTONIC, the clock value is given by an architecture-dependent high
  *   resolution counter, with a precision independent from the system clock tick
  *   duration.
+ * - CLOCK_HOST_REALTIME, the clock value as seen by the host, typically
+ *   Linux. Resolution and precision depend on the host, but it is guaranteed
+ *   that both, host and Xenomai, see the same information.
  *
- * @param clock_id clock identifier, either CLOCK_REALTIME or CLOCK_MONOTONIC;
+ * @param clock_id clock identifier, either CLOCK_REALTIME, CLOCK_MONOTONIC,
+ *        or CLOCK_HOST_REALTIME;
  *
  * @param tp the address where the value of the specified clock will be stored.
  *
@@ -126,6 +207,13 @@ int clock_gettime(clockid_t clock_id, struct timespec *tp)
 		    xnarch_uldivrem(cpu_time, ONE_BILLION, &tp->tv_nsec);
 		break;
 
+	case CLOCK_HOST_REALTIME:
+		if (do_clock_host_realtime(tp) != 0) {
+			thread_set_errno(EINVAL);
+			return -1;
+		}
+		break;
+
 	default:
 		thread_set_errno(EINVAL);
 		return -1;
-- 
1.6.4

[Xenomai-core] [PATCH 6/7] posix: Userspace hostrt reading without switching to kernel mode

[Wolfgang Mauerer]

From: Wolfgang Mauerer (none) <wolfgang@domain.hid>

We can do this since the data are on the shared semaphore heap.
The basis data structure is placed so that it is accessible from
both the Linux kernel and Xenomai kernel/userland. This also
requires to make the structure work with both kernel and userland
definitions for elementary data types.

We use a seqlock retry mechanism to ensure that we obtain a
consistent data set.

Signed-off-by: Wolfgang Mauerer <wolfgang.mauerer@domain.hid>
Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
---
 include/nucleus/Makefile.am    |    1 +
 include/nucleus/seqlock_user.h |   57 +++++++++++++++++++++++++++++++++++
 src/skins/posix/clock.c        |   65 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 123 insertions(+), 0 deletions(-)
 create mode 100644 include/nucleus/seqlock_user.h

diff --git a/include/nucleus/Makefile.am b/include/nucleus/Makefile.am
index b04d7f6..9a72b24 100644
--- a/include/nucleus/Makefile.am
+++ b/include/nucleus/Makefile.am
@@ -35,5 +35,6 @@ includesub_HEADERS = \
 	trace.h \
 	types.h \
 	vdso.h \
+	seqlock_user.h \
 	version.h \
 	xenomai.h
diff --git a/include/nucleus/seqlock_user.h b/include/nucleus/seqlock_user.h
new file mode 100644
index 0000000..598d4da
--- /dev/null
+++ b/include/nucleus/seqlock_user.h
@@ -0,0 +1,57 @@
+#ifndef __SEQLOCK_USER_H
+#define __SEQLOCK_USER_H
+
+/* Originally from the linux kernel, adapted for userland and Xenomai */
+
+#include <asm/xenomai/atomic.h>
+
+typedef struct seqcount {
+	unsigned sequence;
+} seqcount_t;
+
+#define SEQCNT_ZERO { 0 }
+#define seqcount_init(x) do { *(x) = (seqcount_t) SEQCNT_ZERO; } while (0)
+
+/* Start of read using pointer to a sequence counter only.  */
+static inline unsigned read_seqcount_begin(const seqcount_t *s)
+{
+	unsigned ret;
+
+repeat:
+	ret = s->sequence;
+	xnarch_read_memory_barrier();
+	if (unlikely(ret & 1)) {
+		cpu_relax();
+		goto repeat;
+	}
+	return ret;
+}
+
+/*
+ * Test if reader processed invalid data because sequence number has changed.
+ */
+static inline int read_seqcount_retry(const seqcount_t *s, unsigned start)
+{
+	xnarch_read_memory_barrier();
+
+	return s->sequence != start;
+}
+
+
+/*
+ * The sequence counter only protects readers from concurrent writers.
+ * Writers must use their own locking.
+ */
+static inline void write_seqcount_begin(seqcount_t *s)
+{
+	s->sequence++;
+	xnarch_write_memory_barrier();
+}
+
+static inline void write_seqcount_end(seqcount_t *s)
+{
+	xnarch_write_memory_barrier();
+	s->sequence++;
+}
+
+#endif
diff --git a/src/skins/posix/clock.c b/src/skins/posix/clock.c
index e27a2ec..19d6c07 100644
--- a/src/skins/posix/clock.c
+++ b/src/skins/posix/clock.c
@@ -25,6 +25,9 @@
 #include <time.h>
 #include <asm/xenomai/arith.h>
 #include <asm-generic/xenomai/timeconv.h>
+#include <nucleus/seqlock_user.h>
+#include <sys/types.h>
+#include <nucleus/vdso.h>
 
 extern int __pse51_muxid;
 
@@ -56,6 +59,63 @@ int __wrap_clock_getres(clockid_t clock_id, struct timespec *tp)
 	return -1;
 }
 
+int __do_clock_host_realtime(struct timespec *ts, void *tzp)
+{
+	int err;
+#ifdef XNARCH_HAVE_NONPRIV_TSC
+	unsigned int seq;
+	cycle_t now, base, mask, cycle_delta;
+	unsigned long mult, shift, nsec, rem;
+	struct xnarch_hostrt_data *hostrt_data;
+
+	if (!xnvdso_test_feature(XNVDSO_FEAT_HOST_REALTIME))
+		return -1;
+
+	hostrt_data = &nkvdso->hostrt_data;
+
+	if (unlikely(!hostrt_data->live))
+		return -1;
+
+	/*
+	 * The following is essentially a verbatim copy of the
+	 * mechanism in the kernel.
+	 */
+retry:
+	seq = read_seqcount_begin(&hostrt_data->seqcount);
+
+	now = __xn_rdtsc();
+	base = hostrt_data->cycle_last;
+	mask = hostrt_data->mask;
+	mult = hostrt_data->mult;
+	shift = hostrt_data->shift;
+	ts->tv_sec = hostrt_data->wall_time_sec;
+	nsec = hostrt_data->wall_time_nsec;
+
+	/* If the data changed during the read, try the
+	   alternative data element */
+	if (read_seqcount_retry(&hostrt_data->seqcount, seq))
+		goto retry;
+
+	cycle_delta = (now - base) & mask;
+	nsec += (cycle_delta * mult) >> shift;
+
+	ts->tv_sec += xnarch_divrem_billion(nsec, &rem);
+	ts->tv_nsec = rem;
+
+	return 0;
+#else /* XNARCH_HAVE_NONPRIV_TSC */
+	err = -XENOMAI_SKINCALL2(__pse51_muxid,
+				 __pse51_clock_gettime,
+				 CLOCK_HOST_REALTIME, ts);
+
+	if (!err)
+		return 0;
+
+	errno = err;
+	return -1;
+#endif /* XNARCH_HAVE_NONPRIV_TSC */
+}
+
 int __wrap_clock_gettime(clockid_t clock_id, struct timespec *tp)
 {
 	int err;
@@ -68,7 +128,11 @@ int __wrap_clock_gettime(clockid_t clock_id, struct timespec *tp)
 		tp->tv_sec = xnarch_divrem_billion(ns, &rem);
 		tp->tv_nsec = rem;
 		return 0;
+	} else if (clock_id == CLOCK_HOST_REALTIME) {
+		err = __do_clock_host_realtime(tp, NULL);
+		goto out;
 	}
+
 #endif /* XNARCH_HAVE_NONPRIV_TSC */
 
 	err = -XENOMAI_SKINCALL2(__pse51_muxid,
@@ -76,6 +140,7 @@ int __wrap_clock_gettime(clockid_t clock_id, struct timespec *tp)
 				 clock_id,
 				 tp);
 
+out:
 	if (!err)
 		return 0;
 
-- 
1.6.4

[Xenomai-core] [PATCH 7/7] posix: Add some example code for CLOCK_HOST_REALTIME

[Wolfgang Mauerer]

... and for reading the contents of the hostrt data.

Signed-off-by: Wolfgang Mauerer <wolfgang.mauerer@domain.hid>
---
 examples/posix/Makefile      |    3 +-
 examples/posix/show_hrtime.c |   82 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 84 insertions(+), 1 deletions(-)
 create mode 100644 examples/posix/show_hrtime.c

diff --git a/examples/posix/Makefile b/examples/posix/Makefile
index 1bf46a4..c5ec8cb 100644
--- a/examples/posix/Makefile
+++ b/examples/posix/Makefile
@@ -1,7 +1,7 @@
 ###### CONFIGURATION ######
 
 ### List of applications to be build
-APPLICATIONS = satch
+APPLICATIONS = satch show_hrtime
 
 ### Note: to override the search path for the xeno-config script, use "make XENO=..."
 
@@ -14,6 +14,7 @@ MODULES = satch
 all::
 
 satch: satch.c
+show_hrtime: show_hrtime.c
 
 
 ###### USER SPACE BUILD (no change required normally) ######
diff --git a/examples/posix/show_hrtime.c b/examples/posix/show_hrtime.c
new file mode 100644
index 0000000..932c9f8
--- /dev/null
+++ b/examples/posix/show_hrtime.c
@@ -0,0 +1,82 @@
+/*
+ * Dump CLOCK_HOST_REALTIME data in the vdso page
+ * Written by Wolfgang Mauerer <wolfgang.mauerer@domain.hid>
+ */
+
+#include <stdio.h>
+#include <sys/mman.h>
+#include <nucleus/vdso.h>
+#include <nucleus/types.h>
+#include <nucleus/seqlock_user.h>
+#include <native/task.h>
+
+extern unsigned long xeno_sem_heap[2];
+static unsigned modeswitches = 0;
+
+void count_modeswitches(int sig __attribute__((unused)))
+{
+	modeswitches++;
+}
+
+int main(int argc, char **argv)
+{
+	int res;
+	struct timespec ts1, ts2;
+
+	mlockall(MCL_CURRENT|MCL_FUTURE);
+
+	if (!xeno_sem_heap[1]) {
+		fprintf(stderr, "Could not determine position of the "
+			"global semaphore heap\n");
+		return 1;
+	}
+
+	if (!xnvdso_test_feature(XNVDSO_FEAT_HOST_REALTIME)) {
+		printf("XNVDSO_FEAT_HOST_REALTIME not available\n");
+		return 1;
+	}
+
+	if (nkvdso->hostrt_data.live)
+		printf("hostrt data area is live\n");
+	else {
+		printf("hostrt data area is not live\n");
+		return 2;
+	}
+
+	printf("Sequence counter : %u\n",
+	       nkvdso->hostrt_data.seqcount.sequence);
+	printf("wall_time_sec    : %ld\n", nkvdso->hostrt_data.wall_time_sec);
+	printf("wall_time_nsec   : %u\n", nkvdso->hostrt_data.wall_time_nsec);
+	printf("wall_to_monotonic\n");
+	printf("          tv_sec : %jd\n",
+	       (intmax_t)nkvdso->hostrt_data.wall_to_monotonic.tv_sec);
+	printf("         tv_nsec : %ld\n",
+	       nkvdso->hostrt_data.wall_to_monotonic.tv_nsec);
+	printf("cycle_last       : %lu\n", nkvdso->hostrt_data.cycle_last);
+	printf("mask             : 0x%lx\n", nkvdso->hostrt_data.mask);
+	printf("mult             : %u\n", nkvdso->hostrt_data.mult);
+	printf("shift            : %u\n\n", nkvdso->hostrt_data.shift);
+
+	res = clock_gettime(CLOCK_REALTIME, &ts1);
+	if (res)
+		printf("clock_gettime(CLOCK_REALTIME) failed!\n");
+
+	signal(SIGXCPU, count_modeswitches);
+	rt_task_set_mode(0, T_WARNSW, NULL);
+	modeswitches = 0;
+	res = clock_gettime(CLOCK_HOST_REALTIME, &ts2);
+	if (res)
+		printf("clock_gettime(CLOCK_HOST_REALTIME) failed!\n");
+
+	if (modeswitches == 1) {
+		printf("CLOCK_HOST_REALTIME caused a mode switch.\n");
+		return 3;
+	}
+
+	rt_task_set_mode(T_PRIMARY, 0, NULL);
+	printf("CLOCK_REALTIME     : tv_sec = %jd, tv_nsec = %ld\n",
+	       ts1.tv_sec, ts1.tv_nsec);
+	printf("CLOCK_HOST_REALTIME: tv_sec = %jd, tv_nsec = %ld\n",
+	       ts2.tv_sec, ts2.tv_nsec);
+	return 0;
+}
-- 
1.6.4

Re: [Xenomai-core] [PATCH 0/7] Host realtime clock support

[Gilles Chanteperdrix]

Wolfgang Mauerer wrote:
> (This is the Xenomai part of the mechanism, please see the ipipe
>  mailing list for the patches that provide the required basis 
>  infrastructure)
> 
> This patch series extends Xenomai with a new clock, CLOCK_HOST_REALTIME.
> It allows for sharing NTP-corrected real time timestamps between
> Linux/ipipe and Xenomai. The data are also available in userspace and can
> be read without switching to kernel mode. Notice, however, that the new
> clock only enables to read to time, but cannot serve as a full time basis.
> Some changes to the ipipe layer are required as basis.
> 
> In contrast to the initial approach, we don't use a transactional mechanism
> to copy the information over from Linux, but use classical synchronisation.
> The code can be compiled in conditionally for both, ipipe and Xenomai. When
> disabled by architectures that don't support apt clock sources, there is
> no runtime-overhead associated with the feature.
> 
> Some points that may require further discussion:
> 
> - POSIX only specifies a few clock_ids, and these have already been
>   extended by the Linux kernel. We use the maximum id (16) for the new
>   clock, but it might also make sense to use 7 (CLOCK_MONOTONIC_COARSE+1)
>   or 4 (CLOCK_THREAD_CPUTIME_ID+1).
> 
> - The current implementation deals with x86_64's TSC. Support for other
>   architectures can be added. Additionally, the user has to make sure that
>   the TSC clock source remains active once selected.  To implement 
>   deactivation (e.g., when the Linux clock source is changed), more 
>   ipipe hooks would be required, though.
> 
>   There are two alternatives including other architectures:
> 
>   * We can create a new clocksource that abstracts the per-architecture
>     differences, and use this clocksource as basis for
>     Xenomai. Essentially, this means mapping all desired
>     non-x86-Clocksources to the interface offered in this patch.
>     This requires more changes in the ipipe layer than variant B, namely,
>   * We can create a union in struct xnvdso of all arch-specific clock
>     datasets and introduce feature flags like XNVDSO_FEAT_HOSTRT_X86,
>     XNVDSO_FEAT_HOSTRT_WHATEVER. The reader-side code then needs to
>     match the data provided, which requires more changes on the
>     Xenomai side.

The dataset is the same on all architectures, since we provide the same
"clocksource abstraction" on the 5 architectures we support: a TSC
emulation. So, a simple approach is simply cut-and-paste the x86
update_vsyscall code for other architectures, another approach is to put
this code in a wrapper which we call on all architectures.

This update_vsyscall code would call ipipe_dispatch_event to pass the
data to Xenomai.

-- 
					    Gilles.

Re: [Xenomai-core] [PATCH 7/7] posix: Add some example code for CLOCK_HOST_REALTIME

[Jan Kiszka]

Wolfgang Mauerer wrote:
> ... and for reading the contents of the hostrt data.
> 

Just realized: Please also update clocktest. Should already work with
the new clock ID, but requires a cosmetic output patch.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH 7/7] posix: Add some example code for CLOCK_HOST_REALTIME

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Wolfgang Mauerer wrote:
>> ... and for reading the contents of the hostrt data.
>>
> 
> Just realized: Please also update clocktest. Should already work with
> the new clock ID, but requires a cosmetic output patch.

Yes, I thought about that. Maybe even if clocktest uses the new
clock_id, we could drop the example?

I do not think it is a good idea to provide as an example code which
uses the internals of the implementation (though it makes sense to use
the implementation internals in the clocktest code). And if we remove
that, only clock_gettime(CLOCK_HOST_REALTIME) remains, which does not
seem to need an example.

-- 
					    Gilles.

[Xenomai-core] [PATCH (7+1)/7] posix: Add some example code for CLOCK_HOST_REALTIME

[Wolfgang Mauerer]

Kiszka, Jan wrote:
> Wolfgang Mauerer wrote:
>> ... and for reading the contents of the hostrt data.
>>
> 
> Just realized: Please also update clocktest. Should already work with
> the new clock ID, but requires a cosmetic output patch.

easy enough -- here you go ;-) (I'll integrate this into the series)

Best, Wolfgang

diff --git a/src/testsuite/clocktest/clocktest.c
b/src/testsuite/clocktest/clocktest.c
index f0a29ba..42f3f0b 100644
--- a/src/testsuite/clocktest/clocktest.c
+++ b/src/testsuite/clocktest/clocktest.c
@@ -234,6 +234,10 @@ int main(int argc, char *argv[])
             printf("CLOCK_MONOTONIC");
             break;

+        case CLOCK_HOST_REALTIME:
+            printf("CLOCK_HOST_REALTIME");
+            break;
+
         default:
             printf("<unknown>");
             break;

Re: [Xenomai-core] [PATCH 7/7] posix: Add some example code for CLOCK_HOST_REALTIME

[Wolfgang Mauerer]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Wolfgang Mauerer wrote:
>>> ... and for reading the contents of the hostrt data.
>>>
>> Just realized: Please also update clocktest. Should already work with
>> the new clock ID, but requires a cosmetic output patch.
> 
> Yes, I thought about that. Maybe even if clocktest uses the new
> clock_id, we could drop the example?
> 
> I do not think it is a good idea to provide as an example code which
> uses the internals of the implementation (though it makes sense to use
> the implementation internals in the clocktest code). And if we remove
> that, only clock_gettime(CLOCK_HOST_REALTIME) remains, which does not
> seem to need an example.
> 

I would not keep it as an example, but as a test case for checking that
nothing is wrong with the data on the shared page. Which does not fit
quite well into clocktest. Although I have no problem with just omitting
the stuff if reading the (internal) content of the data page is deemed
inappropriate.

Regards, Wolfgang

Re: [Xenomai-core] [PATCH 7/7] posix: Add some example code for CLOCK_HOST_REALTIME

[Gilles Chanteperdrix]

Wolfgang Mauerer wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Wolfgang Mauerer wrote:
>>>> ... and for reading the contents of the hostrt data.
>>>>
>>> Just realized: Please also update clocktest. Should already work with
>>> the new clock ID, but requires a cosmetic output patch.
>> Yes, I thought about that. Maybe even if clocktest uses the new
>> clock_id, we could drop the example?
>>
>> I do not think it is a good idea to provide as an example code which
>> uses the internals of the implementation (though it makes sense to use
>> the implementation internals in the clocktest code). And if we remove
>> that, only clock_gettime(CLOCK_HOST_REALTIME) remains, which does not
>> seem to need an example.
>>
> 
> I would not keep it as an example, but as a test case for checking that
> nothing is wrong with the data on the shared page. Which does not fit
> quite well into clocktest. Although I have no problem with just omitting
> the stuff if reading the (internal) content of the data page is deemed
> inappropriate.

Well, I see nothing wrong with checking the internals at the beginning
of clocktest is the clockid passed to clocktest is CLOCK_HOST_REALTIME.
But Jan may have another opinion, since he is the one who wrote this code.


-- 
					    Gilles.

Re: [Xenomai-core] [PATCH 7/7] posix: Add some example code for CLOCK_HOST_REALTIME

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Wolfgang Mauerer wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Wolfgang Mauerer wrote:
>>>>> ... and for reading the contents of the hostrt data.
>>>>>
>>>> Just realized: Please also update clocktest. Should already work with
>>>> the new clock ID, but requires a cosmetic output patch.
>>> Yes, I thought about that. Maybe even if clocktest uses the new
>>> clock_id, we could drop the example?
>>>
>>> I do not think it is a good idea to provide as an example code which
>>> uses the internals of the implementation (though it makes sense to use
>>> the implementation internals in the clocktest code). And if we remove
>>> that, only clock_gettime(CLOCK_HOST_REALTIME) remains, which does not
>>> seem to need an example.
>>>
>> I would not keep it as an example, but as a test case for checking that
>> nothing is wrong with the data on the shared page. Which does not fit
>> quite well into clocktest. Although I have no problem with just omitting
>> the stuff if reading the (internal) content of the data page is deemed
>> inappropriate.
> 
> Well, I see nothing wrong with checking the internals at the beginning
> of clocktest is the clockid passed to clocktest is CLOCK_HOST_REALTIME.
> But Jan may have another opinion, since he is the one who wrote this code.

If clock_gettime(CLOCK_HOST_REALTIME) succeeds, I don't think we need to
do anything special. But if it should fail, dumping a more detailed
reason based on those additional checks in the example would be helpful.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH 0/7] Host realtime clock support

[Wolfgang Mauerer]

Gilles Chanteperdrix wrote:
> Wolfgang Mauerer wrote:
>> (This is the Xenomai part of the mechanism, please see the ipipe
>>  mailing list for the patches that provide the required basis 
>>  infrastructure)
>>
>> This patch series extends Xenomai with a new clock, CLOCK_HOST_REALTIME.
>> It allows for sharing NTP-corrected real time timestamps between
>> Linux/ipipe and Xenomai. The data are also available in userspace and can
>> be read without switching to kernel mode. Notice, however, that the new
>> clock only enables to read to time, but cannot serve as a full time basis.
>> Some changes to the ipipe layer are required as basis.
>>
>> In contrast to the initial approach, we don't use a transactional mechanism
>> to copy the information over from Linux, but use classical synchronisation.
>> The code can be compiled in conditionally for both, ipipe and Xenomai. When
>> disabled by architectures that don't support apt clock sources, there is
>> no runtime-overhead associated with the feature.
>>
>> Some points that may require further discussion:
>>
>> - POSIX only specifies a few clock_ids, and these have already been
>>   extended by the Linux kernel. We use the maximum id (16) for the new
>>   clock, but it might also make sense to use 7 (CLOCK_MONOTONIC_COARSE+1)
>>   or 4 (CLOCK_THREAD_CPUTIME_ID+1).
>>
>> - The current implementation deals with x86_64's TSC. Support for other
>>   architectures can be added. Additionally, the user has to make sure that
>>   the TSC clock source remains active once selected.  To implement 
>>   deactivation (e.g., when the Linux clock source is changed), more 
>>   ipipe hooks would be required, though.
>>
>>   There are two alternatives including other architectures:
>>
>>   * We can create a new clocksource that abstracts the per-architecture
>>     differences, and use this clocksource as basis for
>>     Xenomai. Essentially, this means mapping all desired
>>     non-x86-Clocksources to the interface offered in this patch.
>>     This requires more changes in the ipipe layer than variant B, namely,
>>   * We can create a union in struct xnvdso of all arch-specific clock
>>     datasets and introduce feature flags like XNVDSO_FEAT_HOSTRT_X86,
>>     XNVDSO_FEAT_HOSTRT_WHATEVER. The reader-side code then needs to
>>     match the data provided, which requires more changes on the
>>     Xenomai side.
> 
> The dataset is the same on all architectures, since we provide the same
> "clocksource abstraction" on the 5 architectures we support: a TSC
> emulation. So, a simple approach is simply cut-and-paste the x86
> update_vsyscall code for other architectures, another approach is to put
> this code in a wrapper which we call on all architectures.

this disables the possibility of using non-TSC time sources that
can also be accessed from userland. That's certainly not a requirement
for us, I'd just like to mention it.

We also need to ensure that the host has not switched away from TSC
because in this case, the NTP correction values delivered from Linux
are for a different clocksource than the one used by Xenomai.
So we need to detect a switch from TSC to non-TSC, which can only be
done in arch-specific code -- I don't see a generic way to know which
clocksources are based on the TSC and which one are not.
> 
> This update_vsyscall code would call ipipe_dispatch_event to pass the
> data to Xenomai.
> 
okay. That seems to have dropped from my radar, as I don't recall having
any issues with this requirement.

Regards, Wolfgang

Re: [Xenomai-core] [PATCH 0/7] Host realtime clock support

[Gilles Chanteperdrix]

Wolfgang Mauerer wrote:
> Gilles Chanteperdrix wrote:
>> Wolfgang Mauerer wrote:
>>> (This is the Xenomai part of the mechanism, please see the ipipe
>>>  mailing list for the patches that provide the required basis 
>>>  infrastructure)
>>>
>>> This patch series extends Xenomai with a new clock, CLOCK_HOST_REALTIME.
>>> It allows for sharing NTP-corrected real time timestamps between
>>> Linux/ipipe and Xenomai. The data are also available in userspace and can
>>> be read without switching to kernel mode. Notice, however, that the new
>>> clock only enables to read to time, but cannot serve as a full time basis.
>>> Some changes to the ipipe layer are required as basis.
>>>
>>> In contrast to the initial approach, we don't use a transactional mechanism
>>> to copy the information over from Linux, but use classical synchronisation.
>>> The code can be compiled in conditionally for both, ipipe and Xenomai. When
>>> disabled by architectures that don't support apt clock sources, there is
>>> no runtime-overhead associated with the feature.
>>>
>>> Some points that may require further discussion:
>>>
>>> - POSIX only specifies a few clock_ids, and these have already been
>>>   extended by the Linux kernel. We use the maximum id (16) for the new
>>>   clock, but it might also make sense to use 7 (CLOCK_MONOTONIC_COARSE+1)
>>>   or 4 (CLOCK_THREAD_CPUTIME_ID+1).
>>>
>>> - The current implementation deals with x86_64's TSC. Support for other
>>>   architectures can be added. Additionally, the user has to make sure that
>>>   the TSC clock source remains active once selected.  To implement 
>>>   deactivation (e.g., when the Linux clock source is changed), more 
>>>   ipipe hooks would be required, though.
>>>
>>>   There are two alternatives including other architectures:
>>>
>>>   * We can create a new clocksource that abstracts the per-architecture
>>>     differences, and use this clocksource as basis for
>>>     Xenomai. Essentially, this means mapping all desired
>>>     non-x86-Clocksources to the interface offered in this patch.
>>>     This requires more changes in the ipipe layer than variant B, namely,
>>>   * We can create a union in struct xnvdso of all arch-specific clock
>>>     datasets and introduce feature flags like XNVDSO_FEAT_HOSTRT_X86,
>>>     XNVDSO_FEAT_HOSTRT_WHATEVER. The reader-side code then needs to
>>>     match the data provided, which requires more changes on the
>>>     Xenomai side.
>> The dataset is the same on all architectures, since we provide the same
>> "clocksource abstraction" on the 5 architectures we support: a TSC
>> emulation. So, a simple approach is simply cut-and-paste the x86
>> update_vsyscall code for other architectures, another approach is to put
>> this code in a wrapper which we call on all architectures.
> 
> this disables the possibility of using non-TSC time sources that
> can also be accessed from userland. That's certainly not a requirement
> for us, I'd just like to mention it.

This would only make sense on x86, as other architectures seem to have
only one clock-source. And since other clocksources than TSC have a
higher overhead, I do not think it is likely that we would like to use
them. Anyway, we can start with TSC and if the need arises, fix that later.

> 
> We also need to ensure that the host has not switched away from TSC
> because in this case, the NTP correction values delivered from Linux
> are for a different clocksource than the one used by Xenomai.
> So we need to detect a switch from TSC to non-TSC, which can only be
> done in arch-specific code -- I don't see a generic way to know which
> clocksources are based on the TSC and which one are not.

Well, all architectures call ipipe_request_tickdev, so, we can check if
the clock pointer passed to update_vsyscall is the same as the one
returned by ipipe_request_tickdev. Do not know if this is really
possible, I would need to check more closely how ipipe_request_tickdev
works.

>> This update_vsyscall code would call ipipe_dispatch_event to pass the
>> data to Xenomai.
>>
> okay. That seems to have dropped from my radar, as I don't recall having
> any issues with this requirement.

I am sure that I always thought that it should be done this way. But
maybe I did not say it... Sorry if that is the case.


-- 
					    Gilles.

Re: [Xenomai-core] [PATCH 0/7] Host realtime clock support

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Wolfgang Mauerer wrote:
>> Gilles Chanteperdrix wrote:
>>> Wolfgang Mauerer wrote:
>>>> (This is the Xenomai part of the mechanism, please see the ipipe
>>>>  mailing list for the patches that provide the required basis 
>>>>  infrastructure)
>>>>
>>>> This patch series extends Xenomai with a new clock, CLOCK_HOST_REALTIME.
>>>> It allows for sharing NTP-corrected real time timestamps between
>>>> Linux/ipipe and Xenomai. The data are also available in userspace and can
>>>> be read without switching to kernel mode. Notice, however, that the new
>>>> clock only enables to read to time, but cannot serve as a full time basis.
>>>> Some changes to the ipipe layer are required as basis.
>>>>
>>>> In contrast to the initial approach, we don't use a transactional mechanism
>>>> to copy the information over from Linux, but use classical synchronisation.
>>>> The code can be compiled in conditionally for both, ipipe and Xenomai. When
>>>> disabled by architectures that don't support apt clock sources, there is
>>>> no runtime-overhead associated with the feature.
>>>>
>>>> Some points that may require further discussion:
>>>>
>>>> - POSIX only specifies a few clock_ids, and these have already been
>>>>   extended by the Linux kernel. We use the maximum id (16) for the new
>>>>   clock, but it might also make sense to use 7 (CLOCK_MONOTONIC_COARSE+1)
>>>>   or 4 (CLOCK_THREAD_CPUTIME_ID+1).
>>>>
>>>> - The current implementation deals with x86_64's TSC. Support for other
>>>>   architectures can be added. Additionally, the user has to make sure that
>>>>   the TSC clock source remains active once selected.  To implement 
>>>>   deactivation (e.g., when the Linux clock source is changed), more 
>>>>   ipipe hooks would be required, though.
>>>>
>>>>   There are two alternatives including other architectures:
>>>>
>>>>   * We can create a new clocksource that abstracts the per-architecture
>>>>     differences, and use this clocksource as basis for
>>>>     Xenomai. Essentially, this means mapping all desired
>>>>     non-x86-Clocksources to the interface offered in this patch.
>>>>     This requires more changes in the ipipe layer than variant B, namely,
>>>>   * We can create a union in struct xnvdso of all arch-specific clock
>>>>     datasets and introduce feature flags like XNVDSO_FEAT_HOSTRT_X86,
>>>>     XNVDSO_FEAT_HOSTRT_WHATEVER. The reader-side code then needs to
>>>>     match the data provided, which requires more changes on the
>>>>     Xenomai side.
>>> The dataset is the same on all architectures, since we provide the same
>>> "clocksource abstraction" on the 5 architectures we support: a TSC
>>> emulation. So, a simple approach is simply cut-and-paste the x86
>>> update_vsyscall code for other architectures, another approach is to put
>>> this code in a wrapper which we call on all architectures.
>> this disables the possibility of using non-TSC time sources that
>> can also be accessed from userland. That's certainly not a requirement
>> for us, I'd just like to mention it.
> 
> This would only make sense on x86, as other architectures seem to have
> only one clock-source. And since other clocksources than TSC have a
> higher overhead, I do not think it is likely that we would like to use
> them.

So far, we insist on running Xenomai only on x86 hardware with
non-broken TSCs. But there are still too many boxes out there (both
Intel and AMD) where TSCs can drift or jump between cores or packages,
even when disabling all the fancy power saving and frequency scaling stuff.

We were lucky in our project not having to deal with such hardware --
for production use. Some intermediate version did suffer from
unsynchronous TSCs.

> Anyway, we can start with TSC and if the need arises, fix that later.

That's true.

> 
>> We also need to ensure that the host has not switched away from TSC
>> because in this case, the NTP correction values delivered from Linux
>> are for a different clocksource than the one used by Xenomai.
>> So we need to detect a switch from TSC to non-TSC, which can only be
>> done in arch-specific code -- I don't see a generic way to know which
>> clocksources are based on the TSC and which one are not.
> 
> Well, all architectures call ipipe_request_tickdev, so, we can check if
> the clock pointer passed to update_vsyscall is the same as the one
> returned by ipipe_request_tickdev. Do not know if this is really
> possible, I would need to check more closely how ipipe_request_tickdev
> works.

Unfortunately, ipipe_request_tickdev is not involved in clocksource
business, it requests a clockevent.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH 4/7] nucleus: Add CLOCK_HOST_REALTIME bits to nkvdso

[Gilles Chanteperdrix]

Wolfgang Mauerer wrote:
> Augment the shared vdso page with all data required to
> implement a clock CLOCK_HOST_REALTIME that provides time
> information synchronised with the NTP-corrected time
> in the Linux kernel.
> 
> The definition of the hostrt data is placed in a separate
> head file so that we can use it irregardless of pervasive
> rt support is compiled in or not.

Ok. Would not it be more simple to define the nkvdso even without
pervasive support?

> +#if defined(CONFIG_XENO_OPT_HOSTRT) && !defined(CONFIG_XENO_OPT_PERVASIVE)
> +	nkhostrt_data = xnarch_alloc_host_mem(sizeof(struct xnarch_hostrt_data));

should be sizeof(*nkhostrt_data)

But why a dynamic allocation at all?


-- 
					    Gilles.

Re: [Xenomai-core] [PATCH 5/7] posix: Support reading the host realtime clock in realtime context

[Gilles Chanteperdrix]

Wolfgang Mauerer wrote:
> Wall time management is typically assisted by the NTP
> protocol in the Linux context, but this information is
> not propagated to Xenomai. This patch adds support
> for a CLOCK_HOST_REALTIME clock id that is coupled to the
> host operating system's realtime clock. The required
> information from the Kernel into Xenomai. The data exchange
> is designed to allow for lockless reading from userland.
> 
> Signed-off-by: Wolfgang Mauerer <wolfgang.mauerer@domain.hid>
> Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
> ---
>  include/posix/time.h     |    2 +
>  ksrc/skins/posix/clock.c |   90 +++++++++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 91 insertions(+), 1 deletions(-)
> 
> diff --git a/include/posix/time.h b/include/posix/time.h
> index 4f2d760..938feb6 100644
> --- a/include/posix/time.h
> +++ b/include/posix/time.h
> @@ -50,6 +50,8 @@
>  #define CLOCK_MONOTONIC 1
>  #endif /* CLOCK_MONOTONIC */
>  
> +#define CLOCK_HOST_REALTIME 16
> +
>  #if defined(__KERNEL__) || defined(__XENO_SIM__)
>  
>  struct sigevent;
> diff --git a/ksrc/skins/posix/clock.c b/ksrc/skins/posix/clock.c
> index 553e123..f5a789b 100644
> --- a/ksrc/skins/posix/clock.c
> +++ b/ksrc/skins/posix/clock.c
> @@ -50,6 +50,13 @@
>   *@{*/
>  
>  #include <posix/thread.h>
> +#include <linux/ipipe_tickdev.h>
> +#include <linux/math64.h>

Do we really need this? Because we probably do not have it in 2.4
kernels. Besides, we do not include linux/ headers in Xenomai code.

> +static int do_clock_host_realtime(struct timespec *tp)
> +{
> +#ifdef CONFIG_XENO_OPT_HOSTRT
> (...)
> +	return 0;
> +#else /* CONFIG_XENO_OPT_HOSTRT */
> +	return -1;

return -EINVAL;

> +	case CLOCK_HOST_REALTIME:
> +		if (do_clock_host_realtime(tp) != 0) {
		rc = do_clock_host_realtime(tp);
		if (rc < 0) {
			thread_set_errno(-rc);
			return -1;
		}


-- 
					    Gilles.

Re: [Xenomai-core] [PATCH 6/7] posix: Userspace hostrt reading without switching to kernel mode

[Gilles Chanteperdrix]

Wolfgang Mauerer wrote:
>  int __wrap_clock_gettime(clockid_t clock_id, struct timespec *tp)
>  {
>  	int err;
> @@ -68,7 +128,11 @@ int __wrap_clock_gettime(clockid_t clock_id, struct timespec *tp)
>  		tp->tv_sec = xnarch_divrem_billion(ns, &rem);
>  		tp->tv_nsec = rem;
>  		return 0;
> +	} else if (clock_id == CLOCK_HOST_REALTIME) {
> +		err = __do_clock_host_realtime(tp, NULL);
> +		goto out;

	swich case here

-- 
					    Gilles.

Re: [Xenomai-core] [PATCH 0/7] Host realtime clock support

[Gilles Chanteperdrix]

Wolfgang Mauerer wrote:
> Some points that may require further discussion:
> 
> - POSIX only specifies a few clock_ids, and these have already been
>   extended by the Linux kernel. We use the maximum id (16) for the new
>   clock, but it might also make sense to use 7 (CLOCK_MONOTONIC_COARSE+1)
>   or 4 (CLOCK_THREAD_CPUTIME_ID+1).

Why are we limited to 16 clocks? I mean we do not go trough any
kernel/glibc path, so it looks like we can use any number. Or did I miss
something?

-- 
					    Gilles.

Re: [Xenomai-core] [PATCH 0/7] Host realtime clock support

[Wolfgang Mauerer]

Gilles Chanteperdrix wrote:
> Wolfgang Mauerer wrote:
>> Gilles Chanteperdrix wrote:
>>> Wolfgang Mauerer wrote:

>>> This update_vsyscall code would call ipipe_dispatch_event to pass the
>>> data to Xenomai.
>>>
>> okay. That seems to have dropped from my radar, as I don't recall having
>> any issues with this requirement.
> 
> I am sure that I always thought that it should be done this way. But
> maybe I did not say it... Sorry if that is the case.

you did say it, in fact. I looked at the interface, but seemingly
forgot to make this change. Will follow in the next submission.

Regards, Wolfgang

Re: [Xenomai-core] [PATCH 5/7] posix: Support reading the host realtime clock in realtime context

[Wolfgang Mauerer]

Gilles Chanteperdrix wrote:
> Wolfgang Mauerer wrote:
>> Wall time management is typically assisted by the NTP
>> protocol in the Linux context, but this information is
>> not propagated to Xenomai. This patch adds support
>> for a CLOCK_HOST_REALTIME clock id that is coupled to the
>> host operating system's realtime clock. The required
>> information from the Kernel into Xenomai. The data exchange
>> is designed to allow for lockless reading from userland.
>>
>> Signed-off-by: Wolfgang Mauerer <wolfgang.mauerer@domain.hid>
>> Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
>> ---
>>  include/posix/time.h     |    2 +
>>  ksrc/skins/posix/clock.c |   90 +++++++++++++++++++++++++++++++++++++++++++++-
>>  2 files changed, 91 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/posix/time.h b/include/posix/time.h
>> index 4f2d760..938feb6 100644
>> --- a/include/posix/time.h
>> +++ b/include/posix/time.h
>> @@ -50,6 +50,8 @@
>>  #define CLOCK_MONOTONIC 1
>>  #endif /* CLOCK_MONOTONIC */
>>  
>> +#define CLOCK_HOST_REALTIME 16
>> +
>>  #if defined(__KERNEL__) || defined(__XENO_SIM__)
>>  
>>  struct sigevent;
>> diff --git a/ksrc/skins/posix/clock.c b/ksrc/skins/posix/clock.c
>> index 553e123..f5a789b 100644
>> --- a/ksrc/skins/posix/clock.c
>> +++ b/ksrc/skins/posix/clock.c
>> @@ -50,6 +50,13 @@
>>   *@{*/
>>  
>>  #include <posix/thread.h>
>> +#include <linux/ipipe_tickdev.h>
>> +#include <linux/math64.h>
> 
> Do we really need this? Because we probably do not have it in 2.4
> kernels. Besides, we do not include linux/ headers in Xenomai code.
> 
right, math64.h should be xenomai/asm-generic/arith.h for
xnarch_divrem_billion(). ipipe_tickdev.h is superfluous since
all definitions go through xnarch and rthal.

>> +static int do_clock_host_realtime(struct timespec *tp)
>> +{
>> +#ifdef CONFIG_XENO_OPT_HOSTRT
>> (...)
>> +	return 0;
>> +#else /* CONFIG_XENO_OPT_HOSTRT */
>> +	return -1;
> 
> return -EINVAL;
> 
>> +	case CLOCK_HOST_REALTIME:
>> +		if (do_clock_host_realtime(tp) != 0) {
> 		rc = do_clock_host_realtime(tp);
> 		if (rc < 0) {
> 			thread_set_errno(-rc);
> 			return -1;
> 		}
> 
> 

Re: [Xenomai-core] [PATCH 0/7] Host realtime clock support

[Wolfgang Mauerer]

Gilles Chanteperdrix wrote:
> Wolfgang Mauerer wrote:
>> Some points that may require further discussion:
>>
>> - POSIX only specifies a few clock_ids, and these have already been
>>   extended by the Linux kernel. We use the maximum id (16) for the new
>>   clock, but it might also make sense to use 7 (CLOCK_MONOTONIC_COARSE+1)
>>   or 4 (CLOCK_THREAD_CPUTIME_ID+1).
> 
> Why are we limited to 16 clocks? I mean we do not go trough any
> kernel/glibc path, so it looks like we can use any number. Or did I miss
> something?
> 

To goal was to find a number that's least surprising and blends best
with the POSIX conventions and the existing numbers in Linux. Maximum
was referring to the definition in the Linux kernel, but I'm happy
to pick any larger number, including 23 and 42 ;-)

Regards, Wolfgang

Re: [Xenomai-core] [PATCH 4/7] nucleus: Add CLOCK_HOST_REALTIME bits to nkvdso

[Wolfgang Mauerer]

Gilles Chanteperdrix wrote:
> Wolfgang Mauerer wrote:
>> Augment the shared vdso page with all data required to
>> implement a clock CLOCK_HOST_REALTIME that provides time
>> information synchronised with the NTP-corrected time
>> in the Linux kernel.
>>
>> The definition of the hostrt data is placed in a separate
>> head file so that we can use it irregardless of pervasive
>> rt support is compiled in or not.
> 
> Ok. Would not it be more simple to define the nkvdso even without
> pervasive support?

Thought about that, but having a shared kernel/userland object
without pervasive RT support seemed a bit unnatural to me.
> 
>> +#if defined(CONFIG_XENO_OPT_HOSTRT) && !defined(CONFIG_XENO_OPT_PERVASIVE)
>> +	nkhostrt_data = xnarch_alloc_host_mem(sizeof(struct xnarch_hostrt_data));
> 
> should be sizeof(*nkhostrt_data)
> 
> But why a dynamic allocation at all?

not really required, can also make it static if you prefer.

Best regards, Wolfgang

Re: [Xenomai-core] [PATCH 4/7] nucleus: Add CLOCK_HOST_REALTIME bits to nkvdso

[Gilles Chanteperdrix]

Wolfgang Mauerer wrote:
> Gilles Chanteperdrix wrote:
>> Wolfgang Mauerer wrote:
>>> Augment the shared vdso page with all data required to
>>> implement a clock CLOCK_HOST_REALTIME that provides time
>>> information synchronised with the NTP-corrected time
>>> in the Linux kernel.
>>>
>>> The definition of the hostrt data is placed in a separate
>>> head file so that we can use it irregardless of pervasive
>>> rt support is compiled in or not.
>> Ok. Would not it be more simple to define the nkvdso even without
>> pervasive support?
> 
> Thought about that, but having a shared kernel/userland object
> without pervasive RT support seemed a bit unnatural to me.

The idea would be to have a static nkvdso in the non-pervasive case, we
do not need the mapping stuff. But at least, if we do this once and for
all for nkvdso, we will not have to repeat the code which handles the
non-pervasive case for all the data in nkvdso which need to exist in
that case.

-- 
					    Gilles.

Re: [Xenomai-core] [PATCH 4/7] nucleus: Add CLOCK_HOST_REALTIME bits to nkvdso

[Wolfgang Mauerer]

Gilles Chanteperdrix wrote:
> Wolfgang Mauerer wrote:
>> Gilles Chanteperdrix wrote:
>>> Wolfgang Mauerer wrote:
>>>> Augment the shared vdso page with all data required to
>>>> implement a clock CLOCK_HOST_REALTIME that provides time
>>>> information synchronised with the NTP-corrected time
>>>> in the Linux kernel.
>>>>
>>>> The definition of the hostrt data is placed in a separate
>>>> head file so that we can use it irregardless of pervasive
>>>> rt support is compiled in or not.
>>> Ok. Would not it be more simple to define the nkvdso even without
>>> pervasive support?
>> Thought about that, but having a shared kernel/userland object
>> without pervasive RT support seemed a bit unnatural to me.
> 
> The idea would be to have a static nkvdso in the non-pervasive case, we
> do not need the mapping stuff. But at least, if we do this once and for
> all for nkvdso, we will not have to repeat the code which handles the
> non-pervasive case for all the data in nkvdso which need to exist in
> that case.

okay, let's do it like this. Might also save a couple of ifdefs.

Regards, Wolfgang