- 20 May, 2021 24 commits
-
-
Signed-off-by:
Philippe Gerum <rpm@xenomai.org> Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com>
-
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:
-
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:
-
Signed-off-by:
Hongzhan Chen <hongzhan.chen@intel.com> Signed-off-by:
-
Since we are dealing with pipeline specific code, we may flatten the call stack by using the Dovetail API directly. Signed-off-by:
-
Force the next tick to be programmed in the hardware as a result of leaving the ONESHOT_STOPPED Signed-off-by:
-
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:
-
Get the name of real device controlled by the proxy tick device. Signed-off-by:
-
Signed-off-by:
-
Signed-off-by:
-
Signed-off-by:
-
Signed-off-by:
-
Signed-off-by:
-
Signed-off-by:
-
inband sirq request through synthetic_irq_domain and free and post srq. Signed-off-by:
-
Signed-off-by:
-
Jan Kiszka authored
Those are not affected by pipeline differences. Signed-off-by: -
Jan Kiszka authored
Signed-off-by: -
Jan Kiszka authored
Signed-off-by: -
enable back tracing for handle_oob_trap_entry Signed-off-by:
-
implement oob irq request and free and post for both TIMER_OOB_IPI and RESCHEDULE_OOB_IPI Signed-off-by:
-
We are using regular request/free_irq under dovetail. This also means there is no extra task to be done in the interrupt enable/disable services. The affinity hint set during request needs to be cleared before freeing the IRQ, or Linux will complain. Signed-off-by:
-
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:
-
This symbol is now I-pipe specific, stick to the I-pipe nomenclature when referring to the high priority execution domain. Signed-off-by:
-
- 12 May, 2021 8 commits
-
-
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: -
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: -
Signed-off-by: -
Signed-off-by: -
set_fs() is on its way out, so we cannot open code a file read operation by calling the VFS handler directly anymore, faking a user address space. We do have kernel interfaces for loading files though, particularly kernel_read_file(). So let's use that one for loading the configuration file contents. Unfortunately, the signature of this service changed during the 5.9-rc cycle, so we have to resort to an ugly wrapper to cope with all supported kernels once again. Sigh. Signed-off-by: -
Since v5.9-rc1, csum_partial_copy_nocheck() forces a zero seed as its last argument to csum_partial(). According to #cc44c17baf7f3, passing a non-zero value would not even yield the proper result on some architectures. However, other locations still expect a non-zero csum seed to be used in the next computation. Meanwhile, some benchmarking (*) revealed that folding copy and checksum operations may not be as optimal as one would have thought when the caches are under pressure, so we switch to a split version, first memcpy() then csum_partial(), so as to always benefit from memcpy() optimizations. As a bonus, we don't have to wrap calls to csum_partial_copy_nocheck() to follow the kernel API change. Instead we can provide a single implementation based on csum_partial() which works with any kernel version. (*) Below are benchmark figures of the csum_copy (folded) vs csum+copy (split) performances in idle vs busy scenarios. Busy means hackbench+dd loop streaming 128M in the background from zero -> null, in order to badly trash the D-caches while the test runs. Three different packet sizes are submitted to checksumming (32, 1024, 1500 bytes), all figures in nanosecs. iMX6QP (Cortex A9) ------------------ === idle CSUM_COPY 32b: min=333, max=1333, avg=439 CSUM_COPY 1024b: min=1000, max=2000, avg=1045 CSUM_COPY 1500b: min=1333, max=2000, avg=1333 COPY+CSUM 32b: min=333, max=1333, avg=443 COPY+CSUM 1024b: min=1000, max=2334, avg=1345 COPY+CSUM 1500b: min=1666, max=2667, avg=1737 === busy CSUM_COPY 32b: min=333, max=4333, avg=466 CSUM_COPY 1024b: min=1000, max=5000, avg=1088 CSUM_COPY 1500b: min=1333, max=5667, avg=1393 COPY+CSUM 32b: min=333, max=1334, avg=454 COPY+CSUM 1024b: min=1000, max=2000, avg=1341 COPY+CSUM 1500b: min=1666, max=2666, avg=1745 C4 (Cortex A55) --------------- === idle CSUM_COPY 32b: min=125, max=791, avg=130 CSUM_COPY 1024b: min=541, max=834, avg=550 CSUM_COPY 1500b: min=708, max=1875, avg=740 COPY+CSUM 32b: min=125, max=167, avg=133 COPY+CSUM 1024b: min=541, max=625, avg=553 COPY+CSUM 1500b: min=708, max=750, avg=730 === busy CSUM_COPY 32b: min=125, max=792, avg=133 CSUM_COPY 1024b: min=500, max=2000, avg=552 CSUM_COPY 1500b: min=708, max=1542, avg=744 COPY+CSUM 32b: min=125, max=375, avg=133 COPY+CSUM 1024b: min=500, max=709, avg=553 COPY+CSUM 1500b: min=708, max=916, avg=743 x86 (atom x5) ------------- === idle CSUM_COPY 32b: min=67, max=590, avg=70 CSUM_COPY 1024b: min=245, max=385, avg=251 CSUM_COPY 1500b: min=343, max=521, avg=350 COPY+CSUM 32b: min=101, max=679, avg=117 COPY+CSUM 1024b: min=296, max=379, avg=298 COPY+CSUM 1500b: min=399, max=502, avg=404 == busy CSUM_COPY 32b: min=65, max=709, avg=71 CSUM_COPY 1024b: min=243, max=702, avg=252 CSUM_COPY 1500b: min=340, max=1055, avg=351 COPY+CSUM 32b: min=100, max=665, avg=120 COPY+CSUM 1024b: min=295, max=669, avg=298 COPY+CSUM 1500b: min=399, max=686, avg=403 arm64 which has no folded csum_copy implementation makes the best of using the split copy+csum path. All architectures seem to benefit from optimized memcpy under load when it comes to the worst case execution time. x86 is less prone to jittery under cache trashing than others as usual, but even there, the max. figures for csum+copy in busy context look pretty much on par with the csum_copy version. Therefore, converting all users to csum+copy makes sense. Signed-off-by: -
Since kernel v5.8, __vmalloc() does not take protection bits as PROT_KERNEL is now wired in. Therefore we cannot disable the cache for the UMM segment via the allocation call directly anymore. This said, we don't support any CPU architecture exhibiting cache aliasing braindamage anymore either (was armv4/v5), so let's convert to the new __vmalloc() call format without bothering for cache settings. Signed-off-by: -
Jan Kiszka authored
This couples pushing to next and stable branches with running xenomai-images, and then only the affected child pipeline. Precondition is setting XENOMAI_IMAGES_TOKEN as protected CI/CD variable. Signed-off-by:
-
- 10 May, 2021 1 commit
-
-
The variant of such helpers which are using a temporary element on the stack work in both worlds, so on systems with 4 and 8 byte time_t. To keep the code as simple as possible we can remove the __BITS_PER_LONG == 64 implementation. Signed-off-by:
Florian Bezdeka <florian.bezdeka@siemens.com> Signed-off-by:
-
- 09 May, 2021 4 commits
-
-
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:
-
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:
-
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: -
On systems using 32 bit for time_t the sem_timedwait syscall was broken because the function used for copying the timeout value from userspace to kernel (=sem_fetch_timeout()) was always copying sizeof(struct timespec64). A 32 bit application (or more specific an application with 4 byte time_t) would only provide sizeof(struct old_timespec32). Notable changes: - The copy operation from userspace to kernel is now already done in the syscall handler. So it is always done and might fail. Reporting a failure is delayed until the timeout is being validated. - Validation: Switched to timespec64_valid() instead of our own check. Signed-off-by:
-
- 05 May, 2021 3 commits
-
-
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:
-
As internal interfaces are gradually being made y2038-safe, the __kernel_timex type should be used internally by the kernel to represent time adjustment parameters. Apply the same reasoning to Cobalt. We still use a legacy y2038-unsafe timex type at the kernel<->user interface boundary (struct __user_old_timex) until libcobalt is y2038-safe. Signed-off-by:
-
As internal interfaces are gradually being made y2038-safe, the itimerspec64 type should be used internally by the kernel to represent interval timer specs. Apply the same reasoning to Cobalt. We still use a legacy y2038-unsafe itimerspec type at the kernel<->user interface boundary (struct __user_old_itimerspec) until libcobalt is y2038-safe. Signed-off-by:
-
