At this chance, stop using the obsolete flush_cache_all() routine
which cannot honor the documented semantics for arm64.

Besides, calibrating the access times to the timer registers in
no-cache conditions does not make sense.

Jan Kiszka authored Dec 06, 2016 and Philippe Gerum committed Jul 03, 2018

At least on x86-64-compat, the missing destruction of the smokey
barriers, specifically their embedded mutexes, cause crashes of the
test. The reason is likely a mismatch between the kernel's and
userland's view on which object is still active, combined with the fact
that userland kept them on the volatile stack.

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

Jan Kiszka authored May 30, 2016 and Philippe Gerum committed Jul 03, 2018

User may expect this (probably last) sleeping service to be available
under Cobalt just like sleep, nanosleep & Co.

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

Does not impact performances and fixes inclusion hell for pulling the
struct xnthread definition for good.

Specific system calls may benefit from dealing with the caller's
runtime mode by themselves, depending on internal information which
the generic syscall dispatcher does not have access to.

To this end, a new syscall mode called "handover" is
introduced. Syscalls bearing this mode bit are always entered from the
current calling domain. The syscall handler may return -ENOSYS to
trigger a switch to the converse domain until all domains have been
visited once, at which point the syscall fails with -ENOSYS
automatically.

For outdated uClibc.

Jan Kiszka authored Mar 08, 2016 and Philippe Gerum committed Jul 03, 2018

Implement pthread_setschedprio on top of pthread_setschedparam_ex with
the help of the new __SCHED_CURRENT policy. This ensures that prio
changes are directly applied to the real-time core, and that with just
a single syscall.

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

Jan Kiszka authored Mar 08, 2016 and Philippe Gerum committed Jul 03, 2018

Define the internal scheduling policy "current": it shall refer to the
target thread's current scheduling policy. This will allow to model
pthread_setschedprio on top of pthread_setschedparam_ex with only a
single syscall.

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

Jan Kiszka authored May 09, 2016 and Philippe Gerum committed Jul 03, 2018

xnsynch_release also needs to tell the caller about the potential need
for a reschedule after deboosting for prio-protection.

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

Jan Kiszka authored May 09, 2016 and Philippe Gerum committed Jul 03, 2018

We currently return the next owner, but no caller of xnsynch_release
evaluates this beyond != NULL and calls xnsched_run in that case.
Simplify the API by returning a need_resched flag directly. This will
also help with fixing the missing reschedule after PP deboost.

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

--enable-lazy-setsched should be given for enabling lazy propagation
of scheduling parameters upon calls to pthread_setschedparam*(),
sched_setscheduler(). Defaults to off.

Do not switch to secondary mode upon schedparam updates for
propagating changes to the regular kernel, if the caller runs in
primary mode when entering pthread_setschedparam*() or
sched_setscheduler(). In such a case, the update request to the
regular kernel is left pending until the target thread resumes
execution in relaxed mode, at which point it is committed.

CAUTION: This mechanism won't update the schedparams cached by the
glibc for the caller in user-space, but this is the deal: we don't
relax threads which issue pthread_setschedparam[_ex]() from primary
mode anymore, but then only the kernel side (Cobalt and the host
kernel) will be aware of the change, and glibc might cache obsolete
information.

If the caller already runs in relaxed mode on entry to these services,
the update request takes place immediately, via the regular (g)libc
calls.

In any case, the new scheduling parameters for the target thread are
immediately applied by Cobalt, regardless of the update path followed
for the regular kernel.

Provide a mechanism for carrying out a lazy propagation of schedparam
updates to the regular kernel, so that userland does not have to
switch to secondary mode for this.

When userland issues sc_cobalt_thread_setschedparam_ex for updating
the scheduling parameters of a Xenomai thread, a request for
propagating this change to the regular kernel is made pending. Such
request will be committed later, either when:

- the thread relaxes if it is running in primary mode when the update
  request is received;

- next time the thread calls back into the Cobalt core as a result of
  receiving a HOME action from a SIGSHADOW notification, which is sent
  if such thread was relaxed at the time of the update request.

As a result, the target thread will have propagated the schedparams
update to the regular kernel as soon as it resumes (relaxed) execution
in user-space.

Jan Kiszka authored Feb 25, 2016 and Philippe Gerum committed Jul 03, 2018

Mutex objects created on the stack must be properly destroyed after use.
Otherwise, succeeding tests that use the same stack layout will consider
them busy and refuse to recreate the mutexes.

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

At this chance, the lock stealing test is also fixed.

Gilles Chanteperdrix authored Oct 11, 2015 and Philippe Gerum committed Jul 03, 2018

Starting with UDP and raw sockets.
Measuring round trip time and checking for lost packets.

All existing ARM64 pipeline implementations provide the
CONFIG_IPIPE_WANT_PREEMPTIBLE_SWITCH knob, which is tested directly in
the Xenomai code base.  No need for CONFIG_XENO_ARCH_UNLOCKED_SWITCH
anymore.

As of fbe1164, CONFIG_XENO_ARCH_UNLOCKED_SWITCH is not tested anymore
in the code base.

CONFIG_XENO_ARCH_UNLOCKED_SWITCH is merely an alias for
CONFIG_IPIPE_WANT_PREEMPTIBLE_SWITCH, which is only meaningful to the
ARM architecture, now that PowerPC dropped such support.

Use the pipeline symbol directly to make the dependency explicit.

This feature never actually brought any measurable gain on powerpc
platforms, compared to the complexity of its implementation in the
pipeline. It was primarily aimed at reducing latency for interrupt
handlers when costly cache and TLB flushes are required to switch
context, at the expense of increasing the scheduling latency.  It
turned out to be counter-productive on common powerpc platforms, with
efficient MMUs.

This feature has been default off for a while now, and 4.1+ pipelines
won't provide support for it anymore. Time to drop support from
Xenomai too.

All pipelines Cobalt can work with (i.e. 3.10+) for the arm
architecture do provide the mm tracking feature unconditionally, so
there is no point in keeping any build switch for it.

All pipelines Cobalt can work with (i.e. 3.10+) for the powerpc
architecture do provide the mm tracking feature unconditionally, so
there is no point in keeping any build switch for it.

We almost always want to track the thread_info structure of the host
task in the core tcb, and doing so is cheap, so there is no point in
building this support conditionally.