- 08 Mar, 2021 40 commits
-
-
Jan Kiszka authored
Not yet compatible with dovetail.
-
Jan Kiszka authored
Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
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>
-
Jan Kiszka authored
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>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
Signed-off-by:
Philippe Gerum <rpm@xenomai.org>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
Signed-off-by:
Philippe Gerum <rpm@xenomai.org>
-
Philippe Gerum authored
Signed-off-by:
Philippe Gerum <rpm@xenomai.org>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
Signed-off-by:
Philippe Gerum <rpm@xenomai.org>
-
Philippe Gerum authored
Signed-off-by:
Philippe Gerum <rpm@xenomai.org>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
Signed-off-by:
Philippe Gerum <rpm@xenomai.org>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
Signed-off-by:
Philippe Gerum <rpm@xenomai.org>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
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>
-
Philippe Gerum authored
Signed-off-by:
Philippe Gerum <rpm@xenomai.org>
-
Philippe Gerum authored
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>
-
hongzha1 via Xenomai authored
Signed-off-by:
hongzha1 <hongzhan.chen@intel.com>
-
Philippe Gerum authored
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>
-
hongzha1 via Xenomai authored
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>
-
hongzha1 via Xenomai authored
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>
-
hongzha1 via Xenomai authored
Get the name of real device controlled by the proxy tick device. Signed-off-by:
hongzha1 <hongzhan.chen@intel.com>
-
hongzha1 via Xenomai authored
Signed-off-by:
hongzha1 <hongzhan.chen@intel.com>
-
Philippe Gerum authored
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>
-
hongzha1 via Xenomai authored
Signed-off-by:
hongzha1 <hongzhan.chen@intel.com>
-
hongzha1 via Xenomai authored
Signed-off-by:
hongzha1 <hongzhan.chen@intel.com>
-
hongzha1 via Xenomai authored
Signed-off-by:
hongzha1 <hongzhan.chen@intel.com>
-