GitLab

Not yet compatible with dovetail.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

The legacy x86_32 architecture is on its way out, with no support from
Dovetail. Besides, it went untested with I-pipe configurations for
many moons.

We still keep 32bit compat mode available for building the user-space
libraries and executables though, along with IA32_EMULATION support in
kernel space to cope with legacy applications.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

After raising the topic of (dis)continuing support for the x32 ABI
multiple times on the mailing list, it turned out that Xenomai has no
known users of this dying ABI. So let's remove it.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Unlike the I-pipe, Dovetail does not need to expose the underlying
timestamp counter to applications. The best equivalent to this counter
would be the common monotonic clock, expressing time as a count of
nanoseconds.

Fork the implementation accordingly between Dovetail and I-pipe
configurations, depending on which pipeline flavour was detected at
init.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

struct xnsched_quota_group needs to be declared, and
syscall_entry/exit classes can collide with the kernel's own classes.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Expiration dates of in-band timers are based on the monotonic time
base read by ktime_get(), which is ok for us to use from non-NMI
context.

At this chance, drop the pointless 'inline' specifier from
pipeline_must_force_program_tick().
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

When Dovetail is enabled in the kernel, we get timestamps for common
clocks (CLOCK_REALTIME, CLOCK_MONOTONIC) from the vDSO-based gettime()
routine as usual.  Do not expect KUSER_TSC support to be there in such
a case, it is not.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

When Dovetail is enabled in the kernel, we get timestamps for common
clocks (CLOCK_REALTIME, CLOCK_MONOTONIC) from the vDSO-based gettime()
routine as usual.  Do not expect KUSER_TSC support to be there in such
a case, it is not.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Dovetail allows the client core to share the common kernel clocks,
including CLOCK_REALTIME. This means the core does not have to
maintain the latter clock, but should hand over all requests to read
the clock and change its epoch to the corresponding in-band kernel
services instead. Conversely, Cobalt should keep on maintaining
CLOCK_REALTIME when running on top of the legacy I-pipe.

Abstract the management of CLOCK_REALTIME to enable such split based
on the underlying IRQ pipeline layer.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

When running on top of Dovetail, we may want to perform a specific
sequence of actions upon notification of a latency peak by some
application. Let's create a dedicated trace call in the API to handle
this particular case, instead of relying on the generic "user_freeze"
event.

NOTE: the new trace call does not return any value, because there is
nothing valuable to receive from a trace call. If required,
xntrace_enabled() should be tested beforehand to figure out whether
the kernel tracer is enabled.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

In order to have applications calling clock_gettime(CLOCK_MONOTONIC)
and Cobalt share the same monotonic source, we need Cobalt to get
timestamps from ktime_get_mono_fast_ns().

Although pipeline_read_cycle_counter() does seem to hint to a raw
source, with Dovetail, our idea of time is directly based on a refined
count of nanoseconds since the epoch, the hardware time counter is
transparent to us. This naming discrepancy comes from the legacy
I-pipe support where we do manipulate hardware ticks internally; this
issue should go when such support is discontinued eventually.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

The ugly big lock must be held when calling xntimer_start(), including
when the in-band timer subsystem wants us to emulate the next host
tick.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Unlike the I-pipe, Dovetail does not copy the work descriptor but
merely hands over the request to the common irq_work() mechanism. We
must guarantee that such descriptor lives in a portion of memory which
won't go stale until the handler has run, which by design can only
happen once the calling out-of-band context unwinds.

Therefore, we have to allocate a request descriptor from the core heap
when issuing a request to enable/disable a particular IRQ channel from
the in-band stage.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Unlike the I-pipe, Dovetail does not copy the work descriptor but
merely hands over the request to the common irq_work() mechanism. We
must guarantee that such descriptor lives in a portion of memory which
won't go stale until the handler has run, which by design can only
happen once the calling out-of-band context unwinds.

Therefore, we have to:

- move the in-band work descriptor used in waking up a relaxing thread
  to this thread's control block.

- allocate a request descriptor from the core heap when issuing a
  request to send an in-band signal to a particular thread. Since we
  might have multiple signals sent concurrently to a single thread,
  having a single request descriptor in the thread control block for
  such purpose is not an option.

- allocate a request descriptor from the core heap when issuing a
  request to wake up the parent task of an emerging Cobalt kthread
  (such task is normally a plain regular Linux one, i.e. it does not
  have any associated Cobalt control block we might use for storing
  the descriptor).
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Unlike the I-pipe, Dovetail does not copy the work descriptor but
merely hands over the request to the common irq_work() mechanism. We
must guarantee that such descriptor lives in a portion of memory which
won't go stale until the handler has run, which by design can only
happen once the calling out-of-band context unwinds.

Therefore, we have to move the in-band work descriptor used in
triggering fd closure off the stack to a global variable, which is
fine since the action of flushing the lingering fds is globally
scoped.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Unlike the I-pipe, Dovetail does not copy the work descriptor but
merely hands over the request to the common irq_work() mechanism. We
must guarantee that such descriptor lives in a portion of memory which
won't go stale until the handler has run, which by design can only
happen once the calling out-of-band context unwinds.

Therefore, we have to move the non-rt signal descriptors off the
stack. When it comes to the basic non-RT signal, the rtdm_nrtsig_t
descriptor itself is a proper place to host the inband work descriptor
which carries out the work under the hood. When a task work needs to
be scheduled, we can dynamically allocate the rtdm_nrtsig_t descriptor
from the core heap.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

With Dovetail in, a thread control block is fully generic, merely
composed of an alternate scheduling control descriptor. Refactor the
definitions of the per-architecture control blocks accordingly.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Dovetail invokes arch_inband_task_init() for each emerging thread in
the system, so that we may initialize our extended state with default
settings. Make sure to intercept this hook in order to start from a
fresh and clean state.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Since 5.6-rc3, former 32bit compatibility types for time-related
structs have been renamed as follows:

compat_timeval -> old_timeval32
compat_timespec -> old_timespec32
compat_itimerspec -> old_itimerspec32

Apply the same changes to the tree, providing backward compatibility
wrappers for pre-5.7 kernels.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Dovetail enables out-of-band access to the vDSO-based clock_gettime()
vcall from applications. If present, select this method instead of
relying on the hardware tick counter for CLOCK_MONOTONIC,
CLOCK_MONOTONIC_RAW, CLOCK_REALTIME and CLOCK_HOST_REALTIME.

At binding time, receiving a null hardware clock frequency from the
core means that we should obtain timestamps directly from the
vDSO-based clock_gettime() vcall (see cobalt_use_legacy_tsc()).

In this mode, Cobalt shares the in-band kernel's idea of time for all
common clocks such as CLOCK_MONOTONIC* and CLOCK_REALTIME. As a
result, CLOCK_HOST_REALTIME refers to the common CLOCK_REALTIME clock.
Furthermore, libcobalt's clock_settime(CLOCK_REALTIME) is delegated to
the underlying *libc, which means the caller may switch to secondary
mode.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

When the core runs on top of Dovetail, all time values are represented
as counts of nanoseconds, in which case a Cobalt tick equals a
nanosecond.

Introduce inline wrappers for tick-to/from-ns conversion which are
nops in the latter case. Cobalt passes us a null clock frequency at
binding time (__cobalt_tsc_clockfreq) when conversion is not needed;
otherwise, the frequency is used in scaled maths for converting
timestamps between their hardware tick and nanosec representation.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: hongzha1 <hongzhan.chen@intel.com>

Since we are dealing with pipeline specific code, we may flatten the
call stack by using the Dovetail API directly.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Force the next tick to be programmed in the hardware as a result of
leaving the ONESHOT_STOPPED
Signed-off-by: hongzha1 <hongzhan.chen@intel.com>

It adds a way to force the timer management code to reprogram the
hardware on option, to make the real device controlled by the proxy
tick again as it leaves the ONESHOT_STOPPED mode. The I-pipe does not
require any further action in this case, leading to a nop.
Signed-off-by: hongzha1 <hongzhan.chen@intel.com>

Get the name of real device controlled by the proxy tick device.
Signed-off-by: hongzha1 <hongzhan.chen@intel.com>

Signed-off-by: hongzha1 <hongzhan.chen@intel.com>

As we move away from the representation of time based on hardware
clock ticks, keeping cobalt_read_hrclock() makes no sense anymore.

This was an internal, undocumented service returning the hardware TSC
value for the platform. The log of commit #d584a57d which introduced it
clearly stated that applications should stick with the common
representation used by clock_gettime(), i.e. nanosecs.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: hongzha1 <hongzhan.chen@intel.com>

Signed-off-by: hongzha1 <hongzhan.chen@intel.com>

Signed-off-by: hongzha1 <hongzhan.chen@intel.com>