The scheduler did not consider the consumed quota during a call to "update"
if the head that consumed the quota was removed from the scheduler. When this
occured, the internal round time did not advance as expected but remained at
its previous value untile the next call to "update" (without a removed head)
This commit introduces a new flag that is set only when the head gets removed
in order to detect and handle the situation correctly on the next call to
"update".
Ref #4151
Ref #4710
Setting the _need_to_schedule member in the 'ready' method of the scheduler
was not done correctly. At least, the _need_to_schedule was set true in
situations were the head was not outdated by the 'ready' operation.
Ref #4151
* Remove *request* in context of: wait, reply, send to shorten it.
* Use ready_to_* instead of can_*, which is regularily used in Genode's APIs
* Replace helping_sink with helping_destination, as destination is more common
Ref genodelabs/genode#4704
The IPC protcol violations are:
* Sending to an unknown thread (cap)
* Waiting for messages if a reply hasn't happened yet
This silents threads that otherwise repeatedly cause kernel messages
about the violation.
Ref genodelabs/genode#4704
* Split the internal state into incoming and outgoing message relations
* Avoid fragmenting of one state like formerly '_state' and '_help'
* Remove pointer to caller, use incoming FIFO instead
This commit fixes at least two bugs that were triggered by tests that
destroy threads in many different states, like run/bomb:
* The '_help' data member was not reset reliable in each situation where a
helping relationship came to an end. However, when we fixed this bug alone
in the old state model, the issues remained. The new state model fixes
this bug as well.
* A thread sometimes referenced an already dead thread as receiver. This caused
the kernel IPC code to access the vtable of an object that didn't exist any
longer. Note that the two threads were not in direct IPC relationship while
the receiver was destroyed, so, there must have been an intermediate node
between them. Due to the complexity of this problem, we eventually gave up
pin-pointing the exact reason in the kernel IPC code. The issue disappeared
with the new state model.
Fixgenodelabs/genode#4704
When running on x86, and riscv never enter the kernel for cache maintainance,
but use the dummy implementation of the generic base library instead.
On ARMv8 it is not necessary to enter privileged mode for cache cleaning, and
unification of instruction/data cache, but only for invalidating cache lines
at all levels, which is necessary for the use cases, where this function it
needed (coherency of DMA memory).
Fixgenodelabs/genode#4339
This call is used to query the cache line size of the underlying CPU.
For now it is only implemented and used by 'arm_v8' platforms.
It does not distinguish between D-/I-cache sizes and always uses the
smallest size. Furthermore it does not account for any discrepancy
in 'big.little' CPUs.
Issue #4339.
To prevent the kernel to deadlock, or call itself with a syscall when
using a lock potentially hold by a core thread, the log console's
backend for core (hw) gets replaced by a specific variant that checks
whether it runs in the kernel context before using the mutex.
Fixgenodelabs/genode#3280
Some signal-heavy scenarios (e.g., libc_integration) produced the
following warning that hinted a data race on signal data in the context
object.
Warning: returning signal with num == 0
The cause was the use of Signal_context::local_submit() in the libc
introduced in
424ed1b79a libc: remove Reconstructible / use local_submit in kernel
in combination with a missing context-mutex aquisition resulting in a
data race on Signal_context::_curr_signal.
Issue #3923
On some Cortex A9 platforms (Qemu 4.2.1 PBXA9), the IRQ status register is not
reliable. Sometimes, it indicates an IRQ too early, i.e., shortly before the
counter wraps. Therefore we have to accomplish wrap detection via counter
comparison only. We check whether the current counter value is higher than the
start counter value of the current timeout.
However, this implies that we have to take care to always read out the counter
before it hits the max timout value again. And, therefore, the max timeout
value has to be far away from the first value the counter has after wrapping.
Consequently, we propagate a max timeout value of half the max counter value.
Fixes#4209
* Modernize routines, eliminate pointers, use constructibles, etc.
* Use absolute time instead of relative time consumption when
updating the scheduler
Ref genodelabs/genode#4151
This commit fixes two issues with the timeout lib and the base-hw src recipe:
* Add source files of timeout lib to recipe content.
The files weren't copied to the depot until now. However, the archive
nonetheless built successfully because of the second issue that is described
below.
* Get rid of the usage of the BASE_DIR variable in the timeout lib.
The BASE_DIR variable always resolves to the repos/base directory even when
building in a depot. That said, the use of BASE_DIR in make-files that are
not part of the build system itself must be avoided. Instead, REP_DIR,
REP_INC_DIR, and $(call select_from_repositories, ...) should be used.
Ref #4209
This patch refines the rules for generating a base-hw src archive
for a given board by enumerating the content of the lib/mk/spec/*
directories instead of including entire directories. This avoids
the inclusion of lib.mk files found in SoC-specific repositories
(like genode-allwinner) in the kernel source archives.
When building a binary archive from such a src archive with the changes
of issue #4599, the build system would otherwise try (and fail) to build
the libraries for the accidentally included lib.mk files.
Instead of having a generic "virt_qemu" board use "virt_qemu_<arch>" in
order to have a clean distinction between boards. Current supported
boards are "virt_qemu_arm_v7a", "virt_qemu_arm_v8a", and
"virt_qemu_riscv".
issue #4034
This commit introduces a hypervisor calling interface. The host kernel can
use it to either switch to a guest VM, or to invalidate the TLB with
regard to a specified VM id.
The VM-specific TLB invalidation is called whenever a VM (Vcpu)
gets destroyed.
Fixgenodelabs/genode#4528
When a PD gets deleted check whether it is active on the current CPU resp. MMU.
If yes, switch to core/kernel's PD to prevent that invalid page-tables or
address-space IDs are still in use. Moreover, whenever we switch to an idle
thread, we switch to kernel/core's PD too. Thereby, we prevent that vanished
PDs are still active on CPUs different from the one, where the core entrypoint
is active, which does the PD deletion.
This whole scheme is only valid under the assumption that core has only one
entrypoint running on one CPU.
Fixgenodelabs/genode#4527
Do not only distinguish core and user threads, but the idle threads too.
Instead of a boolean value, introduce a new thread type.
Ref genodelabs/genode#4527
Genode code already expects MMU to be disabled when starting the
kernel. It is enabled eventually in Bootstrap::Platform::enable_mmu,
after setting up translation tables. Unfortunately nothing ensures
this is actually the case. If MMU happens to be enabled when entering
the kernel things go downhill pretty fast after we start messing with
TTBR.
This patch ensures MMU is disabled for EL1, EL2, EL3 dependent on the
exception level of the CPU core, which is entering the kernel.
This should allow base-hw to start correctly on Quartz64 A board.
The `lookup_translation` function got introduced and is used only in the
context to proof whether a cache maintainance function can be executed
safely by the kernel. Unfortunately, it did not checked write permissions,
which can lead to permission faults. This commit restricts the lookup
function to only succeed when the target page is writeable. Consequently,
the lookup function gets renamed to `lookup_rw_translation`.
Fixgenodelabs/genode#4348
According to ARM Cortex-A55 Core Technical Reference Manual r1p0 the
lowest 8 bits (Aff0) of MPIDR register represent thread IDs within a
multi-threaded core. The actual core identification bits are in Aff1.
This layout can be identified by checking the MT bit of MPIDR register.
Basically, if MT=1 core id is in Aff1, if MT=0 core id is in Aff0.
Without this change Genode will identify all CPU cores on A55 as primary
(0) core.
Its worth to mention that Cortex-A55 by itself is not a multi-threaded
CPU. Aff0 values are always expected to be 0 for pure A55 cores. A55
cores can however be paired with cores that are multi-threaded. To
support such big.LITTLE CPUs in Genode we'd probably need to add a
different mechanism for mapping MPIDR values to logical, contignous
core IDs which Genode expects.
Ref:
https://developer.arm.com/documentation/100442/0100/register-descriptions/aarch64-system-registers/mpidr-el1--multiprocessor-affinity-register--el1?lang=en
The soft ABI implies purely software floating point implementation.
This is not the case for Genode however. For example core's
exception_vector.S uses vmsr instruction. This builds fine with with
GCC based toolchain, but clang with integrated-as complains:
src/core/spec/arm/exception_vector.S:122:2: error: instruction requires: VFP2
vmsr fpexc, r1
^
Fix this by passing softfp to mfloat-abi command on ARMv7. This allows
usage of FP HW, but implies soft-floating point ABI.
Issue #4421
According to C++11 reference:
"If the strictest (largest) alignas on a declaration is weaker than
the alignment it would have without any alignas specifiers (that is,
weaker than its natural alignment or weaker than alignas on another
declaration of the same object or type), the program is ill-formed:"
https://en.cppreference.com/w/cpp/language/alignas
The code requests 4 byte alignment for Genode::Arm_cpu::Context.
The Context structure inherits Genode::Arm_cpu::Fpu_context which
has minimum alignment requirement of 8 bytes, due to uint64_t d0_d31
member. This makes the 4 byte value in Context's alignas specifier
invalid (smaller than allowed minimum).
Similar situation takes place in Arm_64 case. The claimed minimum
alignment of Context is 8 bytes, but the fpu_state member imposes 16
bytes alignment (explicitly specified in Fpu_state declaration).
In both cases the code builds fine with GCC 8.3.0, but fails with
clang which claims that "requested alignment is less than minimum
alignment of X for type", where X is 8 on ARM and 16 on AArch64.
Ref: https://eel.is/c++draft/dcl.align#5
Issue #4421
Even though the use of the C++ exception mechanism (and the implicit use
of the cxx heap) is not a problem at the server side, this patch
nevertheless replaces the exception-based return-value handling to make
the code consistent with the ipc_call path.
Issue #3612
