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.

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

Return to eager switching, since user-space applications use FPU
registers even when not using the FPU, but use an auxiliary backup area
when the "TIF_FOREIGN_FPSTATE" bit is set, in order to avoid clobbering
the saved FPU state.

We don't want GCC to apply any callee-saved logic to fpsimd registers
in fp_regs_set() before fp_regs_check() can verify their contents, but
we still want GCC to know about the registers we have clobbered.

Instead of open coding a copy of the regular context switching code,
use __switch_to() directly, assuming the pipeline properly serializes
switches from all domains.

Don Mahurin authored Sep 14, 2015 and Philippe Gerum committed Jul 03, 2018

The arm mayday implementation was not correct for arm64. Replace with empty implementation.
Handle mayday in the linux domain, using xnthread_relax. This change is essentially the same as the general change proposed in the 'Mayday issues again' discussion (Jan Kiszka, Jun 21), though only applied to arch/arm64.