On 03/11/2023 16:41, Benjamin Beichler wrote:
In time travel mode, the internal time is only advanced at discrete
synchronization points, while the TSC register continuously increases.
Although the TSC registers remain accessible, we remove the TSC flags to
indicate to programs that properly chec
In time travel mode, the internal time is only advanced at discrete
synchronization points, while the TSC register continuously increases.
Although the TSC registers remain accessible, we remove the TSC flags to
indicate to programs that properly check the TSC flag before reading
that the CPU lacks
This change permits interrupts on serial lines in time travel mode,
especially in external mode. However, these interrupts are processed
with the simple handler that does not provide any acknowledgment.
Signed-off-by: Benjamin Beichler
---
arch/um/drivers/line.c | 8
1 file changed, 4 i
Some userspace programs use the current timestamp as a looping condition
(directly or indirectly), which can lead to infinite loops in TT-mode
since the timestamp doesn't change until the next time step.
Commit 065038706f77 ("um: Support time travel mode") introduced a
workaround by always inserti
Although the information for the next requested time was already sent in
a prior message, this change introduces the otherwise unused time
variable in the TT message. This addition enables an extra consistency
check and can otherwise be ignored.
Signed-off-by: Benjamin Beichler
---
arch/um/kerne
Use in uml drivers, which do not need more than scheduling the interrupt
at the time of a follow up timetravel GET-Message.
Signed-off-by: Benjamin Beichler
---
arch/um/include/shared/irq_user.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/um/include/shared/irq_user.h
b/arch/
/um/kernel/time.c | 62 ++
arch/um/kernel/um_arch.c | 4 ++-
include/uapi/linux/um_timetravel.h | 6 ++--
6 files changed, 111 insertions(+), 21 deletions(-)
---
base-commit: 21e80f3841c01aeaf32d7aee7bbc87b3db1aa0c6
change-id: 20231103-bb-
When the timetravel ext modus is used, accessing the timetravel event
list can be interrupted by a message on the timetravel socket in the
SIGIO signal handler. This interruption can potentially modify the event
list, leading to race conditions that cause deadlocks in the timetravel
protocol or dis
The Timetravel socket can be read from the SIGIO handler, which may
catch a RUN message that was expected to be received in the wait loop.
It can happen that the device simulation only "created" one interrupt,
but an uncertain (i.e., hard to predict by the calendar/device
simulation) number of SIG
Allow the so called Calendar (or simulation master) to request the
latest timetravel event. This can be used in situations, where the
former request message from UML to Calendar was missed.
Signed-off-by: Benjamin Beichler
---
arch/um/kernel/time.c | 6 ++
1 file changed, 6 insertions(+)
di
The UBD driver employs multiple threads to enhance block device accesses
in userspace. These threads communicate via pipes and are triggered by
interrupts that utilize the SIGIO handler.
However, in TT mode, both inf-cpu and external modes, this asynchronous,
multithreaded request processing lead
The number of UM_TIMETRAVEL_REQUEST msgs is tried to reduced, if they
are redundant via the time_travel_ext_prev_request_valid flag. This can
create a race condition, when an interrupt happens and the idle loop
wants to wait.
This means, sometimes the UM_TIMETRAVEL_REQUEST are sent(when the idle
l
Given the presence of numerous timer_read calls in well-behaved code
within the kernel and userspace, particularly those that do not employ
busy loops, we introduce a delay in reading the timer only after several
consecutive attempts (currently set at 10).
Unfortunately, it is challenging to diffe
13 matches
Mail list logo
