GitLab

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

I-pipe makes sure that arguments of compat calls are ordered just like
native calls. Dovetail does not. But it is better to use the kernel's
syscall_get_arguments for retrieving the arguments anyway. Introduce
pipeline_get_syscall_args to abstract that difference.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

A process is now marked for COW-breaking on fork() upon the first call
to dovetail_init_altsched(), and must ensure its memory is locked via
a call to mlockall(MCL_CURRENT|MCL_FUTURE) as usual.

As a result, force_commit_memory() became pointless and was removed
from the Dovetail interface.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Make sure not to raise XNSCHED when setting up the root thread, so
that we can't start rescheduling from irq_exit_pipeline() before all
CPUs have their runqueue fully built.

At this chance, add the missing tracepoint reporting a remote
scheduling request.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

In case libcobalt is build with -D_TIME_BITS=64
sc_cobalt_sem_timedwait64 will be used instead of
sc_cobalt_sem_timedwait.
Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>

Introducing a new smokey plugin that can be extended for all kind of
y2038 tests. For now we are testing the new sc_cobalt_sem_timedwait64
syscall without using any libc wrappers provided by libcobalt.
Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>

Implementation is heavily inspired by the sem_timedwait syscall,
but expecting time64 based timespec / timeout.

We need two new syscall handlers:
  - The native one (COBALT_SYSCALL()) to get 32 bit kernels time64
    aware. This handler is added for 64 bit kernels as well, but not
    used. As we don't have separate syscall tables for this both
    worlds we have to add it.

 - The compat handler (COBALT_SYSCALL32emu()) for x32 or x86
   applications running on an x86_64 kernel. Otherwise the redirection
   to the compat / emulation syscalls is broken.
Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>

Initialise and start a real-time task on specified cpu.

Introduce rtdm_task_affinity as base called by other init
task services to avoid code duplication.
Signed-off-by: hongzha1 <hongzhan.chen@intel.com>

Initialise timer on specified cpu.
Signed-off-by: hongzha1 <hongzhan.chen@intel.com>

Dovetail provides a fast service to escalate the caller to out-of-band
mode for executing a routine (run_oob_call()), which we use to enforce
primary mode in ___xnsched_run() to schedule out the relaxing thread.

Due to the way run_oob_call() works, enabling hardirqs during this
transition can trigger a subtle bug caused by the relaxing thread to
be switched out, as a result of taking an interrupt during the irqs on
section, before __xnsched_run() actually runs on behalf of
xnthread_relax() -> xnthread_suspend().

This may lead to a breakage of the inband interrupt state, revealed by
lockdep complaining about a HARDIRQ-IN-W -> HARDIRQ-ON-W situation,
when finalize_task_switch() runs for reconciling both the in-band and
Xenomai scheduler states.

Re-enabling hard irqs before switching out the relaxing thread was
throught as a mean to reduce the scope of the interrupt-free section
while relaxing a thread with the I-pipe, which unlike Dovetail
requires us to open code an escalation service based on triggering a
synthetic interrupt.

We differentiate the behavior between the I-pipe and Dovetail by
abstracting the related bits as pipeline_leave_oob_unlock(), keeping
the current implementation unchanged for the I-pipe.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

At this chance, fix stale and missing copyright notices. Specifically,
Dmitriy Cherkasov <dmitriy@mperpetuo.com> is the original author of
the Xenomai/arm64 port, based on the ARM implementation; add credit
where it is due.

In the same move, introduce SPDX tags as replacement for GPL
boilerplate for the altered files.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Ask for switching back to oob mode once ptrace core tell that
current is resuming from a stopped state, leaving space for
other runnable RT threads of the process to take over.
Signed-off-by: hongzha1 <hongzhan.chen@intel.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>

The license notice for arch/arm/dovetail/machine.c is fixed in order
to match the remaining code, which is [1] for the prefaulting handler,
and myself for the rest.

[1] from Xenomai v2.5-rc1:

commit 8421cc62
Author: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Date:   Sat Nov 15 23:45:24 2008 +0000

    Fault heaps memory on ARM
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>

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>