2019-08-25 17:49:17 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2006-01-19 09:42:42 +08:00
|
|
|
/*
|
2015-11-03 00:16:37 +08:00
|
|
|
* Copyright (C) 2015 Anton Ivanov (aivanov@{brocade.com,kot-begemot.co.uk})
|
|
|
|
* Copyright (C) 2015 Thomas Meyer (thomas@m3y3r.de)
|
|
|
|
* Copyright (C) 2012-2014 Cisco Systems
|
2007-10-16 16:27:00 +08:00
|
|
|
* Copyright (C) 2000 - 2007 Jeff Dike (jdike@{addtoit,linux.intel}.com)
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
* Copyright (C) 2019 Intel Corporation
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
|
2008-02-05 14:31:14 +08:00
|
|
|
#include <linux/clockchips.h>
|
2008-04-29 15:59:18 +08:00
|
|
|
#include <linux/init.h>
|
2008-02-05 14:31:14 +08:00
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include <linux/jiffies.h>
|
2015-11-03 00:16:37 +08:00
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/spinlock.h>
|
2008-02-05 14:31:14 +08:00
|
|
|
#include <linux/threads.h>
|
|
|
|
#include <asm/irq.h>
|
|
|
|
#include <asm/param.h>
|
2012-10-08 10:27:32 +08:00
|
|
|
#include <kern_util.h>
|
|
|
|
#include <os.h>
|
2020-02-13 21:26:44 +08:00
|
|
|
#include <linux/time-internal.h>
|
2020-02-13 21:26:47 +08:00
|
|
|
#include <linux/um_timetravel.h>
|
2019-05-27 16:34:27 +08:00
|
|
|
#include <shared/init.h>
|
|
|
|
|
|
|
|
#ifdef CONFIG_UML_TIME_TRAVEL_SUPPORT
|
|
|
|
enum time_travel_mode time_travel_mode;
|
2020-02-13 21:26:47 +08:00
|
|
|
EXPORT_SYMBOL_GPL(time_travel_mode);
|
2019-05-27 16:34:27 +08:00
|
|
|
|
|
|
|
static bool time_travel_start_set;
|
|
|
|
static unsigned long long time_travel_start;
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
static unsigned long long time_travel_time;
|
|
|
|
static LIST_HEAD(time_travel_events);
|
2020-12-14 05:18:18 +08:00
|
|
|
static LIST_HEAD(time_travel_irqs);
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
static unsigned long long time_travel_timer_interval;
|
|
|
|
static unsigned long long time_travel_next_event;
|
|
|
|
static struct time_travel_event time_travel_timer_event;
|
2020-02-13 21:26:47 +08:00
|
|
|
static int time_travel_ext_fd = -1;
|
|
|
|
static unsigned int time_travel_ext_waiting;
|
|
|
|
static bool time_travel_ext_prev_request_valid;
|
|
|
|
static unsigned long long time_travel_ext_prev_request;
|
|
|
|
static bool time_travel_ext_free_until_valid;
|
|
|
|
static unsigned long long time_travel_ext_free_until;
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
|
|
|
|
static void time_travel_set_time(unsigned long long ns)
|
|
|
|
{
|
|
|
|
if (unlikely(ns < time_travel_time))
|
|
|
|
panic("time-travel: time goes backwards %lld -> %lld\n",
|
|
|
|
time_travel_time, ns);
|
um: Simplify os_idle_sleep() and sleep longer
There really is no reason to pass the amount of time we should
sleep, especially since it's just hard-coded to one second.
Additionally, one second isn't really all that long, and as we
are expecting to be woken up by a signal, we can sleep longer
and avoid doing some work every second, so replace the current
clock_nanosleep() with just an empty select() that can _only_
be woken up by a signal.
We can also remove the deliver_alarm() since we don't need to
do that when we got e.g. SIGIO that woke us up, and if we got
SIGALRM the signal handler will actually (have) run, so it's
just unnecessary extra work.
Similarly, in time-travel mode, just program the wakeup event
from idle to be S64_MAX, which is basically the most you could
ever simulate to. Of course, you should already have an event
in the list that's earlier and will cause a wakeup, normally
that's the regular timer interrupt, though in suspend it may
(later) also be an RTC event. Since actually getting to this
point would be a bug and you can't ever get out again, panic()
on it in the time control code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-12-03 03:58:04 +08:00
|
|
|
else if (unlikely(ns >= S64_MAX))
|
|
|
|
panic("The system was going to sleep forever, aborting");
|
|
|
|
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
time_travel_time = ns;
|
|
|
|
}
|
|
|
|
|
2020-02-13 21:26:47 +08:00
|
|
|
enum time_travel_message_handling {
|
|
|
|
TTMH_IDLE,
|
|
|
|
TTMH_POLL,
|
|
|
|
TTMH_READ,
|
|
|
|
};
|
|
|
|
|
|
|
|
static void time_travel_handle_message(struct um_timetravel_msg *msg,
|
|
|
|
enum time_travel_message_handling mode)
|
|
|
|
{
|
|
|
|
struct um_timetravel_msg resp = {
|
|
|
|
.op = UM_TIMETRAVEL_ACK,
|
|
|
|
};
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/*
|
um: time-travel/signals: fix ndelay() in interrupt
We should be able to ndelay() from any context, even from an
interrupt context! However, this is broken (not functionally,
but locking-wise) in time-travel because we'll get into the
time-travel code and enable interrupts to handle messages on
other time-travel aware subsystems (only virtio for now).
Luckily, I've already reworked the time-travel aware signal
(interrupt) delivery for suspend/resume to have a time travel
handler, which runs directly in the context of the signal and
not from the Linux interrupt.
In order to fix this time-travel issue then, we need to do a
few things:
1) rework the signal handling code to call time-travel handlers
(only) if interrupts are disabled but signals aren't blocked,
instead of marking it only pending there. This is needed to
not deadlock other communication.
2) rework time-travel to not enable interrupts while it's
waiting for a message;
3) rework time-travel to not (just) disable interrupts but
rather block signals at a lower level while it needs them
disabled for communicating with the controller.
Finally, since now we can actually spend even virtual time
in interrupts-disabled sections, the delay warning when we
deliver a time-travel delayed interrupt is no longer valid,
things can (and should) now get delayed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-03-05 20:19:56 +08:00
|
|
|
* We can't unlock here, but interrupt signals with a timetravel_handler
|
|
|
|
* (see um_request_irq_tt) get to the timetravel_handler anyway.
|
2020-02-13 21:26:47 +08:00
|
|
|
*/
|
|
|
|
if (mode != TTMH_READ) {
|
um: time-travel/signals: fix ndelay() in interrupt
We should be able to ndelay() from any context, even from an
interrupt context! However, this is broken (not functionally,
but locking-wise) in time-travel because we'll get into the
time-travel code and enable interrupts to handle messages on
other time-travel aware subsystems (only virtio for now).
Luckily, I've already reworked the time-travel aware signal
(interrupt) delivery for suspend/resume to have a time travel
handler, which runs directly in the context of the signal and
not from the Linux interrupt.
In order to fix this time-travel issue then, we need to do a
few things:
1) rework the signal handling code to call time-travel handlers
(only) if interrupts are disabled but signals aren't blocked,
instead of marking it only pending there. This is needed to
not deadlock other communication.
2) rework time-travel to not enable interrupts while it's
waiting for a message;
3) rework time-travel to not (just) disable interrupts but
rather block signals at a lower level while it needs them
disabled for communicating with the controller.
Finally, since now we can actually spend even virtual time
in interrupts-disabled sections, the delay warning when we
deliver a time-travel delayed interrupt is no longer valid,
things can (and should) now get delayed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-03-05 20:19:56 +08:00
|
|
|
BUG_ON(mode == TTMH_IDLE && !irqs_disabled());
|
2020-09-10 17:31:12 +08:00
|
|
|
|
2020-02-13 21:26:47 +08:00
|
|
|
while (os_poll(1, &time_travel_ext_fd) != 0) {
|
2020-09-10 17:31:12 +08:00
|
|
|
/* nothing */
|
2020-02-13 21:26:47 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = os_read_file(time_travel_ext_fd, msg, sizeof(*msg));
|
|
|
|
|
|
|
|
if (ret == 0)
|
|
|
|
panic("time-travel external link is broken\n");
|
|
|
|
if (ret != sizeof(*msg))
|
|
|
|
panic("invalid time-travel message - %d bytes\n", ret);
|
|
|
|
|
|
|
|
switch (msg->op) {
|
|
|
|
default:
|
|
|
|
WARN_ONCE(1, "time-travel: unexpected message %lld\n",
|
|
|
|
(unsigned long long)msg->op);
|
|
|
|
break;
|
|
|
|
case UM_TIMETRAVEL_ACK:
|
|
|
|
return;
|
|
|
|
case UM_TIMETRAVEL_RUN:
|
|
|
|
time_travel_set_time(msg->time);
|
|
|
|
break;
|
|
|
|
case UM_TIMETRAVEL_FREE_UNTIL:
|
|
|
|
time_travel_ext_free_until_valid = true;
|
|
|
|
time_travel_ext_free_until = msg->time;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2020-09-10 17:31:13 +08:00
|
|
|
resp.seq = msg->seq;
|
2020-02-13 21:26:47 +08:00
|
|
|
os_write_file(time_travel_ext_fd, &resp, sizeof(resp));
|
|
|
|
}
|
|
|
|
|
|
|
|
static u64 time_travel_ext_req(u32 op, u64 time)
|
|
|
|
{
|
|
|
|
static int seq;
|
|
|
|
int mseq = ++seq;
|
|
|
|
struct um_timetravel_msg msg = {
|
|
|
|
.op = op,
|
|
|
|
.time = time,
|
|
|
|
.seq = mseq,
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
um: time-travel/signals: fix ndelay() in interrupt
We should be able to ndelay() from any context, even from an
interrupt context! However, this is broken (not functionally,
but locking-wise) in time-travel because we'll get into the
time-travel code and enable interrupts to handle messages on
other time-travel aware subsystems (only virtio for now).
Luckily, I've already reworked the time-travel aware signal
(interrupt) delivery for suspend/resume to have a time travel
handler, which runs directly in the context of the signal and
not from the Linux interrupt.
In order to fix this time-travel issue then, we need to do a
few things:
1) rework the signal handling code to call time-travel handlers
(only) if interrupts are disabled but signals aren't blocked,
instead of marking it only pending there. This is needed to
not deadlock other communication.
2) rework time-travel to not enable interrupts while it's
waiting for a message;
3) rework time-travel to not (just) disable interrupts but
rather block signals at a lower level while it needs them
disabled for communicating with the controller.
Finally, since now we can actually spend even virtual time
in interrupts-disabled sections, the delay warning when we
deliver a time-travel delayed interrupt is no longer valid,
things can (and should) now get delayed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-03-05 20:19:56 +08:00
|
|
|
* We need to block even the timetravel handlers of SIGIO here and
|
|
|
|
* only restore their use when we got the ACK - otherwise we may
|
|
|
|
* (will) get interrupted by that, try to queue the IRQ for future
|
|
|
|
* processing and thus send another request while we're still waiting
|
|
|
|
* for an ACK, but the peer doesn't know we got interrupted and will
|
|
|
|
* send the ACKs in the same order as the message, but we'd need to
|
|
|
|
* see them in the opposite order ...
|
2020-02-13 21:26:47 +08:00
|
|
|
*
|
|
|
|
* This wouldn't matter *too* much, but some ACKs carry the
|
|
|
|
* current time (for UM_TIMETRAVEL_GET) and getting another
|
|
|
|
* ACK without a time would confuse us a lot!
|
|
|
|
*
|
|
|
|
* The sequence number assignment that happens here lets us
|
|
|
|
* debug such message handling issues more easily.
|
|
|
|
*/
|
um: time-travel/signals: fix ndelay() in interrupt
We should be able to ndelay() from any context, even from an
interrupt context! However, this is broken (not functionally,
but locking-wise) in time-travel because we'll get into the
time-travel code and enable interrupts to handle messages on
other time-travel aware subsystems (only virtio for now).
Luckily, I've already reworked the time-travel aware signal
(interrupt) delivery for suspend/resume to have a time travel
handler, which runs directly in the context of the signal and
not from the Linux interrupt.
In order to fix this time-travel issue then, we need to do a
few things:
1) rework the signal handling code to call time-travel handlers
(only) if interrupts are disabled but signals aren't blocked,
instead of marking it only pending there. This is needed to
not deadlock other communication.
2) rework time-travel to not enable interrupts while it's
waiting for a message;
3) rework time-travel to not (just) disable interrupts but
rather block signals at a lower level while it needs them
disabled for communicating with the controller.
Finally, since now we can actually spend even virtual time
in interrupts-disabled sections, the delay warning when we
deliver a time-travel delayed interrupt is no longer valid,
things can (and should) now get delayed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-03-05 20:19:56 +08:00
|
|
|
block_signals_hard();
|
2020-02-13 21:26:47 +08:00
|
|
|
os_write_file(time_travel_ext_fd, &msg, sizeof(msg));
|
|
|
|
|
|
|
|
while (msg.op != UM_TIMETRAVEL_ACK)
|
|
|
|
time_travel_handle_message(&msg, TTMH_READ);
|
|
|
|
|
|
|
|
if (msg.seq != mseq)
|
|
|
|
panic("time-travel: ACK message has different seqno! op=%d, seq=%d != %d time=%lld\n",
|
|
|
|
msg.op, msg.seq, mseq, msg.time);
|
|
|
|
|
|
|
|
if (op == UM_TIMETRAVEL_GET)
|
|
|
|
time_travel_set_time(msg.time);
|
um: time-travel/signals: fix ndelay() in interrupt
We should be able to ndelay() from any context, even from an
interrupt context! However, this is broken (not functionally,
but locking-wise) in time-travel because we'll get into the
time-travel code and enable interrupts to handle messages on
other time-travel aware subsystems (only virtio for now).
Luckily, I've already reworked the time-travel aware signal
(interrupt) delivery for suspend/resume to have a time travel
handler, which runs directly in the context of the signal and
not from the Linux interrupt.
In order to fix this time-travel issue then, we need to do a
few things:
1) rework the signal handling code to call time-travel handlers
(only) if interrupts are disabled but signals aren't blocked,
instead of marking it only pending there. This is needed to
not deadlock other communication.
2) rework time-travel to not enable interrupts while it's
waiting for a message;
3) rework time-travel to not (just) disable interrupts but
rather block signals at a lower level while it needs them
disabled for communicating with the controller.
Finally, since now we can actually spend even virtual time
in interrupts-disabled sections, the delay warning when we
deliver a time-travel delayed interrupt is no longer valid,
things can (and should) now get delayed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-03-05 20:19:56 +08:00
|
|
|
unblock_signals_hard();
|
2020-02-13 21:26:47 +08:00
|
|
|
|
|
|
|
return msg.time;
|
|
|
|
}
|
|
|
|
|
|
|
|
void __time_travel_wait_readable(int fd)
|
|
|
|
{
|
|
|
|
int fds[2] = { fd, time_travel_ext_fd };
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (time_travel_mode != TT_MODE_EXTERNAL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
while ((ret = os_poll(2, fds))) {
|
|
|
|
struct um_timetravel_msg msg;
|
|
|
|
|
|
|
|
if (ret == 1)
|
|
|
|
time_travel_handle_message(&msg, TTMH_READ);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__time_travel_wait_readable);
|
|
|
|
|
|
|
|
static void time_travel_ext_update_request(unsigned long long time)
|
|
|
|
{
|
|
|
|
if (time_travel_mode != TT_MODE_EXTERNAL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* asked for exactly this time previously */
|
|
|
|
if (time_travel_ext_prev_request_valid &&
|
|
|
|
time == time_travel_ext_prev_request)
|
|
|
|
return;
|
|
|
|
|
2020-12-11 16:01:14 +08:00
|
|
|
/*
|
|
|
|
* if we're running and are allowed to run past the request
|
|
|
|
* then we don't need to update it either
|
|
|
|
*/
|
|
|
|
if (!time_travel_ext_waiting && time_travel_ext_free_until_valid &&
|
|
|
|
time < time_travel_ext_free_until)
|
|
|
|
return;
|
|
|
|
|
2020-02-13 21:26:47 +08:00
|
|
|
time_travel_ext_prev_request = time;
|
|
|
|
time_travel_ext_prev_request_valid = true;
|
|
|
|
time_travel_ext_req(UM_TIMETRAVEL_REQUEST, time);
|
|
|
|
}
|
|
|
|
|
|
|
|
void __time_travel_propagate_time(void)
|
|
|
|
{
|
2020-12-04 19:34:34 +08:00
|
|
|
static unsigned long long last_propagated;
|
|
|
|
|
|
|
|
if (last_propagated == time_travel_time)
|
|
|
|
return;
|
|
|
|
|
2020-02-13 21:26:47 +08:00
|
|
|
time_travel_ext_req(UM_TIMETRAVEL_UPDATE, time_travel_time);
|
2020-12-04 19:34:34 +08:00
|
|
|
last_propagated = time_travel_time;
|
2020-02-13 21:26:47 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__time_travel_propagate_time);
|
|
|
|
|
|
|
|
/* returns true if we must do a wait to the simtime device */
|
|
|
|
static bool time_travel_ext_request(unsigned long long time)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If we received an external sync point ("free until") then we
|
|
|
|
* don't have to request/wait for anything until then, unless
|
|
|
|
* we're already waiting.
|
|
|
|
*/
|
|
|
|
if (!time_travel_ext_waiting && time_travel_ext_free_until_valid &&
|
|
|
|
time < time_travel_ext_free_until)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
time_travel_ext_update_request(time);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void time_travel_ext_wait(bool idle)
|
|
|
|
{
|
|
|
|
struct um_timetravel_msg msg = {
|
|
|
|
.op = UM_TIMETRAVEL_ACK,
|
|
|
|
};
|
|
|
|
|
|
|
|
time_travel_ext_prev_request_valid = false;
|
2020-12-11 16:01:14 +08:00
|
|
|
time_travel_ext_free_until_valid = false;
|
2020-02-13 21:26:47 +08:00
|
|
|
time_travel_ext_waiting++;
|
|
|
|
|
|
|
|
time_travel_ext_req(UM_TIMETRAVEL_WAIT, -1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Here we are deep in the idle loop, so we have to break out of the
|
|
|
|
* kernel abstraction in a sense and implement this in terms of the
|
|
|
|
* UML system waiting on the VQ interrupt while sleeping, when we get
|
|
|
|
* the signal it'll call time_travel_ext_vq_notify_done() completing the
|
|
|
|
* call.
|
|
|
|
*/
|
|
|
|
while (msg.op != UM_TIMETRAVEL_RUN)
|
|
|
|
time_travel_handle_message(&msg, idle ? TTMH_IDLE : TTMH_POLL);
|
|
|
|
|
|
|
|
time_travel_ext_waiting--;
|
|
|
|
|
|
|
|
/* we might request more stuff while polling - reset when we run */
|
|
|
|
time_travel_ext_prev_request_valid = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void time_travel_ext_get_time(void)
|
|
|
|
{
|
|
|
|
time_travel_ext_req(UM_TIMETRAVEL_GET, -1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __time_travel_update_time(unsigned long long ns, bool idle)
|
|
|
|
{
|
|
|
|
if (time_travel_mode == TT_MODE_EXTERNAL && time_travel_ext_request(ns))
|
|
|
|
time_travel_ext_wait(idle);
|
|
|
|
else
|
|
|
|
time_travel_set_time(ns);
|
|
|
|
}
|
|
|
|
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
static struct time_travel_event *time_travel_first_event(void)
|
|
|
|
{
|
|
|
|
return list_first_entry_or_null(&time_travel_events,
|
|
|
|
struct time_travel_event,
|
|
|
|
list);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __time_travel_add_event(struct time_travel_event *e,
|
|
|
|
unsigned long long time)
|
|
|
|
{
|
|
|
|
struct time_travel_event *tmp;
|
|
|
|
bool inserted = false;
|
um: time-travel: rework interrupt handling in ext mode
In external time-travel mode, where time is controlled via the
controller application socket, interrupt handling is a little
tricky. For example on virtio, the following happens:
* we receive a message (that requires an ACK) on the vhost-user socket
* we add a time-travel event to handle the interrupt
(this causes communication on the time socket)
* we ACK the original vhost-user message
* we then handle the interrupt once the event is triggered
This protocol ensures that the sender of the interrupt only continues
to run in the simulation when the time-travel event has been added.
So far, this was only done in the virtio driver, but it was actually
wrong, because only virtqueue interrupts were handled this way, and
config change interrupts were handled immediately. Additionally, the
messages were actually handled in the real Linux interrupt handler,
but Linux interrupt handlers are part of the simulation and shouldn't
run while there's no time event.
To really do this properly and only handle all kinds of interrupts in
the time-travel event when we are scheduled to run in the simulation,
rework this to plug in to the lower interrupt layers in UML directly:
Add a um_request_irq_tt() function that let's a time-travel aware
driver request an interrupt with an additional timetravel_handler()
that is called outside of the context of the simulation, to handle
the message only. It then adds an event to the time-travel calendar
if necessary, and no "real" Linux code runs outside of the time
simulation.
This also hooks in with suspend/resume properly now, since this new
timetravel_handler() can run while Linux is suspended and interrupts
are disabled, and decide to wake up (or not) the system based on the
message it received. Importantly in this case, it ACKs the message
before the system even resumes and interrupts are re-enabled, thus
allowing the simulation to progress properly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-12-15 17:52:24 +08:00
|
|
|
unsigned long flags;
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
|
|
|
|
if (e->pending)
|
|
|
|
return;
|
|
|
|
|
|
|
|
e->pending = true;
|
|
|
|
e->time = time;
|
|
|
|
|
um: time-travel: rework interrupt handling in ext mode
In external time-travel mode, where time is controlled via the
controller application socket, interrupt handling is a little
tricky. For example on virtio, the following happens:
* we receive a message (that requires an ACK) on the vhost-user socket
* we add a time-travel event to handle the interrupt
(this causes communication on the time socket)
* we ACK the original vhost-user message
* we then handle the interrupt once the event is triggered
This protocol ensures that the sender of the interrupt only continues
to run in the simulation when the time-travel event has been added.
So far, this was only done in the virtio driver, but it was actually
wrong, because only virtqueue interrupts were handled this way, and
config change interrupts were handled immediately. Additionally, the
messages were actually handled in the real Linux interrupt handler,
but Linux interrupt handlers are part of the simulation and shouldn't
run while there's no time event.
To really do this properly and only handle all kinds of interrupts in
the time-travel event when we are scheduled to run in the simulation,
rework this to plug in to the lower interrupt layers in UML directly:
Add a um_request_irq_tt() function that let's a time-travel aware
driver request an interrupt with an additional timetravel_handler()
that is called outside of the context of the simulation, to handle
the message only. It then adds an event to the time-travel calendar
if necessary, and no "real" Linux code runs outside of the time
simulation.
This also hooks in with suspend/resume properly now, since this new
timetravel_handler() can run while Linux is suspended and interrupts
are disabled, and decide to wake up (or not) the system based on the
message it received. Importantly in this case, it ACKs the message
before the system even resumes and interrupts are re-enabled, thus
allowing the simulation to progress properly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-12-15 17:52:24 +08:00
|
|
|
local_irq_save(flags);
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
list_for_each_entry(tmp, &time_travel_events, list) {
|
|
|
|
/*
|
|
|
|
* Add the new entry before one with higher time,
|
|
|
|
* or if they're equal and both on stack, because
|
|
|
|
* in that case we need to unwind the stack in the
|
|
|
|
* right order, and the later event (timer sleep
|
|
|
|
* or such) must be dequeued first.
|
|
|
|
*/
|
|
|
|
if ((tmp->time > e->time) ||
|
|
|
|
(tmp->time == e->time && tmp->onstack && e->onstack)) {
|
|
|
|
list_add_tail(&e->list, &tmp->list);
|
|
|
|
inserted = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!inserted)
|
|
|
|
list_add_tail(&e->list, &time_travel_events);
|
|
|
|
|
|
|
|
tmp = time_travel_first_event();
|
2020-02-13 21:26:47 +08:00
|
|
|
time_travel_ext_update_request(tmp->time);
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
time_travel_next_event = tmp->time;
|
um: time-travel: rework interrupt handling in ext mode
In external time-travel mode, where time is controlled via the
controller application socket, interrupt handling is a little
tricky. For example on virtio, the following happens:
* we receive a message (that requires an ACK) on the vhost-user socket
* we add a time-travel event to handle the interrupt
(this causes communication on the time socket)
* we ACK the original vhost-user message
* we then handle the interrupt once the event is triggered
This protocol ensures that the sender of the interrupt only continues
to run in the simulation when the time-travel event has been added.
So far, this was only done in the virtio driver, but it was actually
wrong, because only virtqueue interrupts were handled this way, and
config change interrupts were handled immediately. Additionally, the
messages were actually handled in the real Linux interrupt handler,
but Linux interrupt handlers are part of the simulation and shouldn't
run while there's no time event.
To really do this properly and only handle all kinds of interrupts in
the time-travel event when we are scheduled to run in the simulation,
rework this to plug in to the lower interrupt layers in UML directly:
Add a um_request_irq_tt() function that let's a time-travel aware
driver request an interrupt with an additional timetravel_handler()
that is called outside of the context of the simulation, to handle
the message only. It then adds an event to the time-travel calendar
if necessary, and no "real" Linux code runs outside of the time
simulation.
This also hooks in with suspend/resume properly now, since this new
timetravel_handler() can run while Linux is suspended and interrupts
are disabled, and decide to wake up (or not) the system based on the
message it received. Importantly in this case, it ACKs the message
before the system even resumes and interrupts are re-enabled, thus
allowing the simulation to progress properly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-12-15 17:52:24 +08:00
|
|
|
local_irq_restore(flags);
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void time_travel_add_event(struct time_travel_event *e,
|
|
|
|
unsigned long long time)
|
|
|
|
{
|
|
|
|
if (WARN_ON(!e->fn))
|
|
|
|
return;
|
|
|
|
|
|
|
|
__time_travel_add_event(e, time);
|
|
|
|
}
|
|
|
|
|
2021-01-15 20:12:18 +08:00
|
|
|
void time_travel_add_event_rel(struct time_travel_event *e,
|
|
|
|
unsigned long long delay_ns)
|
|
|
|
{
|
|
|
|
time_travel_add_event(e, time_travel_time + delay_ns);
|
|
|
|
}
|
|
|
|
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
void time_travel_periodic_timer(struct time_travel_event *e)
|
|
|
|
{
|
|
|
|
time_travel_add_event(&time_travel_timer_event,
|
|
|
|
time_travel_time + time_travel_timer_interval);
|
|
|
|
deliver_alarm();
|
|
|
|
}
|
|
|
|
|
2020-12-14 05:18:18 +08:00
|
|
|
void deliver_time_travel_irqs(void)
|
|
|
|
{
|
|
|
|
struct time_travel_event *e;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't do anything for most cases. Note that because here we have
|
|
|
|
* to disable IRQs (and re-enable later) we'll actually recurse at
|
|
|
|
* the end of the function, so this is strictly necessary.
|
|
|
|
*/
|
|
|
|
if (likely(list_empty(&time_travel_irqs)))
|
|
|
|
return;
|
|
|
|
|
|
|
|
local_irq_save(flags);
|
|
|
|
irq_enter();
|
|
|
|
while ((e = list_first_entry_or_null(&time_travel_irqs,
|
|
|
|
struct time_travel_event,
|
|
|
|
list))) {
|
|
|
|
list_del(&e->list);
|
|
|
|
e->pending = false;
|
|
|
|
e->fn(e);
|
|
|
|
}
|
|
|
|
irq_exit();
|
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
|
|
|
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
static void time_travel_deliver_event(struct time_travel_event *e)
|
|
|
|
{
|
2020-02-13 21:26:47 +08:00
|
|
|
if (e == &time_travel_timer_event) {
|
|
|
|
/*
|
|
|
|
* deliver_alarm() does the irq_enter/irq_exit
|
|
|
|
* by itself, so must handle it specially here
|
|
|
|
*/
|
|
|
|
e->fn(e);
|
2020-12-14 05:18:18 +08:00
|
|
|
} else if (irqs_disabled()) {
|
|
|
|
list_add_tail(&e->list, &time_travel_irqs);
|
|
|
|
/*
|
|
|
|
* set pending again, it was set to false when the
|
|
|
|
* event was deleted from the original list, but
|
|
|
|
* now it's still pending until we deliver the IRQ.
|
|
|
|
*/
|
|
|
|
e->pending = true;
|
2020-02-13 21:26:47 +08:00
|
|
|
} else {
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
local_irq_save(flags);
|
|
|
|
irq_enter();
|
|
|
|
e->fn(e);
|
|
|
|
irq_exit();
|
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
}
|
|
|
|
|
2021-01-15 20:12:18 +08:00
|
|
|
bool time_travel_del_event(struct time_travel_event *e)
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
{
|
um: time-travel: rework interrupt handling in ext mode
In external time-travel mode, where time is controlled via the
controller application socket, interrupt handling is a little
tricky. For example on virtio, the following happens:
* we receive a message (that requires an ACK) on the vhost-user socket
* we add a time-travel event to handle the interrupt
(this causes communication on the time socket)
* we ACK the original vhost-user message
* we then handle the interrupt once the event is triggered
This protocol ensures that the sender of the interrupt only continues
to run in the simulation when the time-travel event has been added.
So far, this was only done in the virtio driver, but it was actually
wrong, because only virtqueue interrupts were handled this way, and
config change interrupts were handled immediately. Additionally, the
messages were actually handled in the real Linux interrupt handler,
but Linux interrupt handlers are part of the simulation and shouldn't
run while there's no time event.
To really do this properly and only handle all kinds of interrupts in
the time-travel event when we are scheduled to run in the simulation,
rework this to plug in to the lower interrupt layers in UML directly:
Add a um_request_irq_tt() function that let's a time-travel aware
driver request an interrupt with an additional timetravel_handler()
that is called outside of the context of the simulation, to handle
the message only. It then adds an event to the time-travel calendar
if necessary, and no "real" Linux code runs outside of the time
simulation.
This also hooks in with suspend/resume properly now, since this new
timetravel_handler() can run while Linux is suspended and interrupts
are disabled, and decide to wake up (or not) the system based on the
message it received. Importantly in this case, it ACKs the message
before the system even resumes and interrupts are re-enabled, thus
allowing the simulation to progress properly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-12-15 17:52:24 +08:00
|
|
|
unsigned long flags;
|
|
|
|
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
if (!e->pending)
|
|
|
|
return false;
|
um: time-travel: rework interrupt handling in ext mode
In external time-travel mode, where time is controlled via the
controller application socket, interrupt handling is a little
tricky. For example on virtio, the following happens:
* we receive a message (that requires an ACK) on the vhost-user socket
* we add a time-travel event to handle the interrupt
(this causes communication on the time socket)
* we ACK the original vhost-user message
* we then handle the interrupt once the event is triggered
This protocol ensures that the sender of the interrupt only continues
to run in the simulation when the time-travel event has been added.
So far, this was only done in the virtio driver, but it was actually
wrong, because only virtqueue interrupts were handled this way, and
config change interrupts were handled immediately. Additionally, the
messages were actually handled in the real Linux interrupt handler,
but Linux interrupt handlers are part of the simulation and shouldn't
run while there's no time event.
To really do this properly and only handle all kinds of interrupts in
the time-travel event when we are scheduled to run in the simulation,
rework this to plug in to the lower interrupt layers in UML directly:
Add a um_request_irq_tt() function that let's a time-travel aware
driver request an interrupt with an additional timetravel_handler()
that is called outside of the context of the simulation, to handle
the message only. It then adds an event to the time-travel calendar
if necessary, and no "real" Linux code runs outside of the time
simulation.
This also hooks in with suspend/resume properly now, since this new
timetravel_handler() can run while Linux is suspended and interrupts
are disabled, and decide to wake up (or not) the system based on the
message it received. Importantly in this case, it ACKs the message
before the system even resumes and interrupts are re-enabled, thus
allowing the simulation to progress properly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-12-15 17:52:24 +08:00
|
|
|
local_irq_save(flags);
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
list_del(&e->list);
|
|
|
|
e->pending = false;
|
um: time-travel: rework interrupt handling in ext mode
In external time-travel mode, where time is controlled via the
controller application socket, interrupt handling is a little
tricky. For example on virtio, the following happens:
* we receive a message (that requires an ACK) on the vhost-user socket
* we add a time-travel event to handle the interrupt
(this causes communication on the time socket)
* we ACK the original vhost-user message
* we then handle the interrupt once the event is triggered
This protocol ensures that the sender of the interrupt only continues
to run in the simulation when the time-travel event has been added.
So far, this was only done in the virtio driver, but it was actually
wrong, because only virtqueue interrupts were handled this way, and
config change interrupts were handled immediately. Additionally, the
messages were actually handled in the real Linux interrupt handler,
but Linux interrupt handlers are part of the simulation and shouldn't
run while there's no time event.
To really do this properly and only handle all kinds of interrupts in
the time-travel event when we are scheduled to run in the simulation,
rework this to plug in to the lower interrupt layers in UML directly:
Add a um_request_irq_tt() function that let's a time-travel aware
driver request an interrupt with an additional timetravel_handler()
that is called outside of the context of the simulation, to handle
the message only. It then adds an event to the time-travel calendar
if necessary, and no "real" Linux code runs outside of the time
simulation.
This also hooks in with suspend/resume properly now, since this new
timetravel_handler() can run while Linux is suspended and interrupts
are disabled, and decide to wake up (or not) the system based on the
message it received. Importantly in this case, it ACKs the message
before the system even resumes and interrupts are re-enabled, thus
allowing the simulation to progress properly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-12-15 17:52:24 +08:00
|
|
|
local_irq_restore(flags);
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2020-02-13 21:26:47 +08:00
|
|
|
static void time_travel_update_time(unsigned long long next, bool idle)
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
{
|
|
|
|
struct time_travel_event ne = {
|
|
|
|
.onstack = true,
|
|
|
|
};
|
|
|
|
struct time_travel_event *e;
|
2020-02-13 21:26:47 +08:00
|
|
|
bool finished = idle;
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
|
|
|
|
/* add it without a handler - we deal with that specifically below */
|
|
|
|
__time_travel_add_event(&ne, next);
|
|
|
|
|
|
|
|
do {
|
|
|
|
e = time_travel_first_event();
|
|
|
|
|
|
|
|
BUG_ON(!e);
|
2020-02-13 21:26:47 +08:00
|
|
|
__time_travel_update_time(e->time, idle);
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
|
|
|
|
/* new events may have been inserted while we were waiting */
|
|
|
|
if (e == time_travel_first_event()) {
|
|
|
|
BUG_ON(!time_travel_del_event(e));
|
|
|
|
BUG_ON(time_travel_time != e->time);
|
|
|
|
|
|
|
|
if (e == &ne) {
|
|
|
|
finished = true;
|
|
|
|
} else {
|
|
|
|
if (e->onstack)
|
|
|
|
panic("On-stack event dequeued outside of the stack! time=%lld, event time=%lld, event=%pS\n",
|
|
|
|
time_travel_time, e->time, e);
|
|
|
|
time_travel_deliver_event(e);
|
|
|
|
}
|
|
|
|
}
|
2020-02-13 21:26:47 +08:00
|
|
|
|
|
|
|
e = time_travel_first_event();
|
|
|
|
if (e)
|
|
|
|
time_travel_ext_update_request(e->time);
|
|
|
|
} while (ne.pending && !finished);
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
|
|
|
|
time_travel_del_event(&ne);
|
|
|
|
}
|
|
|
|
|
2020-02-13 21:26:48 +08:00
|
|
|
void time_travel_ndelay(unsigned long nsec)
|
|
|
|
{
|
|
|
|
time_travel_update_time(time_travel_time + nsec, false);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(time_travel_ndelay);
|
|
|
|
|
2020-02-13 21:26:47 +08:00
|
|
|
void time_travel_add_irq_event(struct time_travel_event *e)
|
|
|
|
{
|
|
|
|
BUG_ON(time_travel_mode != TT_MODE_EXTERNAL);
|
|
|
|
|
|
|
|
time_travel_ext_get_time();
|
|
|
|
/*
|
|
|
|
* We could model interrupt latency here, for now just
|
|
|
|
* don't have any latency at all and request the exact
|
|
|
|
* same time (again) to run the interrupt...
|
|
|
|
*/
|
|
|
|
time_travel_add_event(e, time_travel_time);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(time_travel_add_irq_event);
|
|
|
|
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
static void time_travel_oneshot_timer(struct time_travel_event *e)
|
|
|
|
{
|
|
|
|
deliver_alarm();
|
|
|
|
}
|
|
|
|
|
um: Simplify os_idle_sleep() and sleep longer
There really is no reason to pass the amount of time we should
sleep, especially since it's just hard-coded to one second.
Additionally, one second isn't really all that long, and as we
are expecting to be woken up by a signal, we can sleep longer
and avoid doing some work every second, so replace the current
clock_nanosleep() with just an empty select() that can _only_
be woken up by a signal.
We can also remove the deliver_alarm() since we don't need to
do that when we got e.g. SIGIO that woke us up, and if we got
SIGALRM the signal handler will actually (have) run, so it's
just unnecessary extra work.
Similarly, in time-travel mode, just program the wakeup event
from idle to be S64_MAX, which is basically the most you could
ever simulate to. Of course, you should already have an event
in the list that's earlier and will cause a wakeup, normally
that's the regular timer interrupt, though in suspend it may
(later) also be an RTC event. Since actually getting to this
point would be a bug and you can't ever get out again, panic()
on it in the time control code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-12-03 03:58:04 +08:00
|
|
|
void time_travel_sleep(void)
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
{
|
um: Simplify os_idle_sleep() and sleep longer
There really is no reason to pass the amount of time we should
sleep, especially since it's just hard-coded to one second.
Additionally, one second isn't really all that long, and as we
are expecting to be woken up by a signal, we can sleep longer
and avoid doing some work every second, so replace the current
clock_nanosleep() with just an empty select() that can _only_
be woken up by a signal.
We can also remove the deliver_alarm() since we don't need to
do that when we got e.g. SIGIO that woke us up, and if we got
SIGALRM the signal handler will actually (have) run, so it's
just unnecessary extra work.
Similarly, in time-travel mode, just program the wakeup event
from idle to be S64_MAX, which is basically the most you could
ever simulate to. Of course, you should already have an event
in the list that's earlier and will cause a wakeup, normally
that's the regular timer interrupt, though in suspend it may
(later) also be an RTC event. Since actually getting to this
point would be a bug and you can't ever get out again, panic()
on it in the time control code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-12-03 03:58:04 +08:00
|
|
|
/*
|
|
|
|
* Wait "forever" (using S64_MAX because there are some potential
|
|
|
|
* wrapping issues, especially with the current TT_MODE_EXTERNAL
|
|
|
|
* controller application.
|
|
|
|
*/
|
|
|
|
unsigned long long next = S64_MAX;
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
|
|
|
|
if (time_travel_mode == TT_MODE_BASIC)
|
|
|
|
os_timer_disable();
|
|
|
|
|
|
|
|
time_travel_update_time(next, true);
|
|
|
|
|
|
|
|
if (time_travel_mode == TT_MODE_BASIC &&
|
|
|
|
time_travel_timer_event.pending) {
|
|
|
|
if (time_travel_timer_event.fn == time_travel_periodic_timer) {
|
|
|
|
/*
|
|
|
|
* This is somewhat wrong - we should get the first
|
|
|
|
* one sooner like the os_timer_one_shot() below...
|
|
|
|
*/
|
|
|
|
os_timer_set_interval(time_travel_timer_interval);
|
|
|
|
} else {
|
|
|
|
os_timer_one_shot(time_travel_timer_event.time - next);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void time_travel_handle_real_alarm(void)
|
|
|
|
{
|
|
|
|
time_travel_set_time(time_travel_next_event);
|
|
|
|
|
|
|
|
time_travel_del_event(&time_travel_timer_event);
|
|
|
|
|
|
|
|
if (time_travel_timer_event.fn == time_travel_periodic_timer)
|
|
|
|
time_travel_add_event(&time_travel_timer_event,
|
|
|
|
time_travel_time +
|
|
|
|
time_travel_timer_interval);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void time_travel_set_interval(unsigned long long interval)
|
|
|
|
{
|
|
|
|
time_travel_timer_interval = interval;
|
|
|
|
}
|
2020-02-13 21:26:47 +08:00
|
|
|
|
|
|
|
static int time_travel_connect_external(const char *socket)
|
|
|
|
{
|
|
|
|
const char *sep;
|
|
|
|
unsigned long long id = (unsigned long long)-1;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
if ((sep = strchr(socket, ':'))) {
|
|
|
|
char buf[25] = {};
|
|
|
|
if (sep - socket > sizeof(buf) - 1)
|
|
|
|
goto invalid_number;
|
|
|
|
|
|
|
|
memcpy(buf, socket, sep - socket);
|
|
|
|
if (kstrtoull(buf, 0, &id)) {
|
|
|
|
invalid_number:
|
|
|
|
panic("time-travel: invalid external ID in string '%s'\n",
|
|
|
|
socket);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
socket = sep + 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
rc = os_connect_socket(socket);
|
|
|
|
if (rc < 0) {
|
|
|
|
panic("time-travel: failed to connect to external socket %s\n",
|
|
|
|
socket);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
time_travel_ext_fd = rc;
|
|
|
|
|
|
|
|
time_travel_ext_req(UM_TIMETRAVEL_START, id);
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
2021-01-15 19:49:45 +08:00
|
|
|
|
|
|
|
static void time_travel_set_start(void)
|
|
|
|
{
|
|
|
|
if (time_travel_start_set)
|
|
|
|
return;
|
|
|
|
|
|
|
|
switch (time_travel_mode) {
|
|
|
|
case TT_MODE_EXTERNAL:
|
|
|
|
time_travel_start = time_travel_ext_req(UM_TIMETRAVEL_GET_TOD, -1);
|
|
|
|
/* controller gave us the *current* time, so adjust by that */
|
|
|
|
time_travel_ext_get_time();
|
|
|
|
time_travel_start -= time_travel_time;
|
|
|
|
break;
|
|
|
|
case TT_MODE_INFCPU:
|
|
|
|
case TT_MODE_BASIC:
|
|
|
|
if (!time_travel_start_set)
|
|
|
|
time_travel_start = os_persistent_clock_emulation();
|
|
|
|
break;
|
|
|
|
case TT_MODE_OFF:
|
|
|
|
/* we just read the host clock with os_persistent_clock_emulation() */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
time_travel_start_set = true;
|
|
|
|
}
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
#else /* CONFIG_UML_TIME_TRAVEL_SUPPORT */
|
2019-05-27 16:34:27 +08:00
|
|
|
#define time_travel_start_set 0
|
|
|
|
#define time_travel_start 0
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
#define time_travel_time 0
|
2020-12-11 16:01:14 +08:00
|
|
|
#define time_travel_ext_waiting 0
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
|
|
|
|
static inline void time_travel_update_time(unsigned long long ns, bool retearly)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void time_travel_handle_real_alarm(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static void time_travel_set_interval(unsigned long long interval)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2021-01-15 19:49:45 +08:00
|
|
|
static inline void time_travel_set_start(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2020-02-13 21:26:47 +08:00
|
|
|
/* fail link if this actually gets used */
|
|
|
|
extern u64 time_travel_ext_req(u32 op, u64 time);
|
|
|
|
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
/* these are empty macros so the struct/fn need not exist */
|
|
|
|
#define time_travel_add_event(e, time) do { } while (0)
|
2021-01-15 20:12:18 +08:00
|
|
|
/* externally not usable - redefine here so we can */
|
|
|
|
#undef time_travel_del_event
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
#define time_travel_del_event(e) do { } while (0)
|
2019-05-27 16:34:27 +08:00
|
|
|
#endif
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-08-02 06:49:17 +08:00
|
|
|
void timer_handler(int sig, struct siginfo *unused_si, struct uml_pt_regs *regs)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2007-10-16 16:27:24 +08:00
|
|
|
unsigned long flags;
|
|
|
|
|
2019-09-10 23:03:53 +08:00
|
|
|
/*
|
|
|
|
* In basic time-travel mode we still get real interrupts
|
|
|
|
* (signals) but since we don't read time from the OS, we
|
|
|
|
* must update the simulated time here to the expiry when
|
|
|
|
* we get a signal.
|
|
|
|
* This is not the case in inf-cpu mode, since there we
|
|
|
|
* never get any real signals from the OS.
|
|
|
|
*/
|
|
|
|
if (time_travel_mode == TT_MODE_BASIC)
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
time_travel_handle_real_alarm();
|
2019-05-27 16:34:27 +08:00
|
|
|
|
2007-10-16 16:27:24 +08:00
|
|
|
local_irq_save(flags);
|
2007-10-16 16:27:25 +08:00
|
|
|
do_IRQ(TIMER_IRQ, regs);
|
2007-10-16 16:27:24 +08:00
|
|
|
local_irq_restore(flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2015-07-16 19:26:31 +08:00
|
|
|
static int itimer_shutdown(struct clock_event_device *evt)
|
2006-01-19 09:42:42 +08:00
|
|
|
{
|
2019-05-27 16:34:27 +08:00
|
|
|
if (time_travel_mode != TT_MODE_OFF)
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
time_travel_del_event(&time_travel_timer_event);
|
2019-05-27 16:34:27 +08:00
|
|
|
|
2020-02-13 21:26:47 +08:00
|
|
|
if (time_travel_mode != TT_MODE_INFCPU &&
|
|
|
|
time_travel_mode != TT_MODE_EXTERNAL)
|
2019-05-27 16:34:27 +08:00
|
|
|
os_timer_disable();
|
|
|
|
|
2015-07-16 19:26:31 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2007-10-16 16:27:24 +08:00
|
|
|
|
2015-07-16 19:26:31 +08:00
|
|
|
static int itimer_set_periodic(struct clock_event_device *evt)
|
|
|
|
{
|
2019-05-27 16:34:27 +08:00
|
|
|
unsigned long long interval = NSEC_PER_SEC / HZ;
|
|
|
|
|
2019-07-22 15:12:56 +08:00
|
|
|
if (time_travel_mode != TT_MODE_OFF) {
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
time_travel_del_event(&time_travel_timer_event);
|
|
|
|
time_travel_set_event_fn(&time_travel_timer_event,
|
|
|
|
time_travel_periodic_timer);
|
|
|
|
time_travel_set_interval(interval);
|
|
|
|
time_travel_add_event(&time_travel_timer_event,
|
|
|
|
time_travel_time + interval);
|
2019-07-22 15:12:56 +08:00
|
|
|
}
|
2019-05-27 16:34:27 +08:00
|
|
|
|
2020-02-13 21:26:47 +08:00
|
|
|
if (time_travel_mode != TT_MODE_INFCPU &&
|
|
|
|
time_travel_mode != TT_MODE_EXTERNAL)
|
2019-05-27 16:34:27 +08:00
|
|
|
os_timer_set_interval(interval);
|
|
|
|
|
2015-07-16 19:26:31 +08:00
|
|
|
return 0;
|
2006-01-19 09:42:42 +08:00
|
|
|
}
|
|
|
|
|
2007-10-16 16:27:25 +08:00
|
|
|
static int itimer_next_event(unsigned long delta,
|
|
|
|
struct clock_event_device *evt)
|
|
|
|
{
|
2019-05-27 16:34:27 +08:00
|
|
|
delta += 1;
|
|
|
|
|
2019-07-22 15:12:56 +08:00
|
|
|
if (time_travel_mode != TT_MODE_OFF) {
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
time_travel_del_event(&time_travel_timer_event);
|
|
|
|
time_travel_set_event_fn(&time_travel_timer_event,
|
|
|
|
time_travel_oneshot_timer);
|
|
|
|
time_travel_add_event(&time_travel_timer_event,
|
|
|
|
time_travel_time + delta);
|
2019-07-22 15:12:56 +08:00
|
|
|
}
|
2019-05-27 16:34:27 +08:00
|
|
|
|
2020-02-13 21:26:47 +08:00
|
|
|
if (time_travel_mode != TT_MODE_INFCPU &&
|
|
|
|
time_travel_mode != TT_MODE_EXTERNAL)
|
2019-05-27 16:34:27 +08:00
|
|
|
return os_timer_one_shot(delta);
|
|
|
|
|
|
|
|
return 0;
|
2007-10-16 16:27:25 +08:00
|
|
|
}
|
|
|
|
|
2015-11-03 00:16:37 +08:00
|
|
|
static int itimer_one_shot(struct clock_event_device *evt)
|
|
|
|
{
|
2019-05-27 16:34:27 +08:00
|
|
|
return itimer_next_event(0, evt);
|
2015-11-03 00:16:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct clock_event_device timer_clockevent = {
|
|
|
|
.name = "posix-timer",
|
2015-07-16 19:26:31 +08:00
|
|
|
.rating = 250,
|
2019-04-11 02:11:23 +08:00
|
|
|
.cpumask = cpu_possible_mask,
|
2015-07-16 19:26:31 +08:00
|
|
|
.features = CLOCK_EVT_FEAT_PERIODIC |
|
|
|
|
CLOCK_EVT_FEAT_ONESHOT,
|
|
|
|
.set_state_shutdown = itimer_shutdown,
|
|
|
|
.set_state_periodic = itimer_set_periodic,
|
2015-11-03 00:16:37 +08:00
|
|
|
.set_state_oneshot = itimer_one_shot,
|
2015-07-16 19:26:31 +08:00
|
|
|
.set_next_event = itimer_next_event,
|
2015-11-03 00:16:37 +08:00
|
|
|
.shift = 0,
|
|
|
|
.max_delta_ns = 0xffffffff,
|
2017-03-31 03:59:42 +08:00
|
|
|
.max_delta_ticks = 0xffffffff,
|
|
|
|
.min_delta_ns = TIMER_MIN_DELTA,
|
|
|
|
.min_delta_ticks = TIMER_MIN_DELTA, // microsecond resolution should be enough for anyone, same as 640K RAM
|
2015-07-16 19:26:31 +08:00
|
|
|
.irq = 0,
|
2015-11-03 00:16:37 +08:00
|
|
|
.mult = 1,
|
2007-10-16 16:27:24 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static irqreturn_t um_timer(int irq, void *dev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2015-11-03 00:16:37 +08:00
|
|
|
if (get_current()->mm != NULL)
|
|
|
|
{
|
|
|
|
/* userspace - relay signal, results in correct userspace timers */
|
|
|
|
os_alarm_process(get_current()->mm->context.id.u.pid);
|
|
|
|
}
|
|
|
|
|
|
|
|
(*timer_clockevent.event_handler)(&timer_clockevent);
|
2006-01-19 09:42:42 +08:00
|
|
|
|
2006-06-30 16:55:56 +08:00
|
|
|
return IRQ_HANDLED;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2016-12-22 03:32:01 +08:00
|
|
|
static u64 timer_read(struct clocksource *cs)
|
2007-10-16 16:27:25 +08:00
|
|
|
{
|
2019-05-27 16:34:27 +08:00
|
|
|
if (time_travel_mode != TT_MODE_OFF) {
|
|
|
|
/*
|
|
|
|
* We make reading the timer cost a bit so that we don't get
|
|
|
|
* stuck in loops that expect time to move more than the
|
|
|
|
* exact requested sleep amount, e.g. python's socket server,
|
|
|
|
* see https://bugs.python.org/issue37026.
|
2020-02-13 21:26:47 +08:00
|
|
|
*
|
|
|
|
* However, don't do that when we're in interrupt or such as
|
|
|
|
* then we might recurse into our own processing, and get to
|
|
|
|
* even more waiting, and that's not good - it messes up the
|
|
|
|
* "what do I do next" and onstack event we use to know when
|
|
|
|
* to return from time_travel_update_time().
|
2019-05-27 16:34:27 +08:00
|
|
|
*/
|
2020-12-11 16:01:14 +08:00
|
|
|
if (!irqs_disabled() && !in_interrupt() && !in_softirq() &&
|
|
|
|
!time_travel_ext_waiting)
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 21:26:45 +08:00
|
|
|
time_travel_update_time(time_travel_time +
|
|
|
|
TIMER_MULTIPLIER,
|
|
|
|
false);
|
2019-05-27 16:34:27 +08:00
|
|
|
return time_travel_time / TIMER_MULTIPLIER;
|
|
|
|
}
|
|
|
|
|
2015-11-03 00:16:37 +08:00
|
|
|
return os_nsecs() / TIMER_MULTIPLIER;
|
2007-10-16 16:27:25 +08:00
|
|
|
}
|
|
|
|
|
2015-11-03 00:16:37 +08:00
|
|
|
static struct clocksource timer_clocksource = {
|
|
|
|
.name = "timer",
|
2007-10-16 16:27:25 +08:00
|
|
|
.rating = 300,
|
2015-11-03 00:16:37 +08:00
|
|
|
.read = timer_read,
|
2007-10-16 16:27:25 +08:00
|
|
|
.mask = CLOCKSOURCE_MASK(64),
|
|
|
|
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
|
|
|
|
};
|
|
|
|
|
2017-09-29 16:07:44 +08:00
|
|
|
static void __init um_timer_setup(void)
|
2006-07-10 19:45:05 +08:00
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2015-11-03 00:16:37 +08:00
|
|
|
err = request_irq(TIMER_IRQ, um_timer, IRQF_TIMER, "hr timer", NULL);
|
2007-10-16 16:27:00 +08:00
|
|
|
if (err != 0)
|
2006-09-26 14:33:05 +08:00
|
|
|
printk(KERN_ERR "register_timer : request_irq failed - "
|
2006-07-10 19:45:05 +08:00
|
|
|
"errno = %d\n", -err);
|
|
|
|
|
2019-05-06 20:39:38 +08:00
|
|
|
err = os_timer_create();
|
2015-11-03 00:16:37 +08:00
|
|
|
if (err != 0) {
|
|
|
|
printk(KERN_ERR "creation of timer failed - errno = %d\n", -err);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = clocksource_register_hz(&timer_clocksource, NSEC_PER_SEC/TIMER_MULTIPLIER);
|
2007-10-16 16:27:25 +08:00
|
|
|
if (err) {
|
2010-04-27 11:25:16 +08:00
|
|
|
printk(KERN_ERR "clocksource_register_hz returned %d\n", err);
|
2007-10-16 16:27:25 +08:00
|
|
|
return;
|
|
|
|
}
|
2015-11-03 00:16:37 +08:00
|
|
|
clockevents_register_device(&timer_clockevent);
|
2006-07-10 19:45:05 +08:00
|
|
|
}
|
|
|
|
|
2017-11-02 20:07:02 +08:00
|
|
|
void read_persistent_clock64(struct timespec64 *ts)
|
2010-07-14 08:56:24 +08:00
|
|
|
{
|
2019-05-27 16:34:27 +08:00
|
|
|
long long nsecs;
|
|
|
|
|
2021-01-15 19:49:45 +08:00
|
|
|
time_travel_set_start();
|
|
|
|
|
2020-12-03 03:58:05 +08:00
|
|
|
if (time_travel_mode != TT_MODE_OFF)
|
2019-05-27 16:34:27 +08:00
|
|
|
nsecs = time_travel_start + time_travel_time;
|
|
|
|
else
|
|
|
|
nsecs = os_persistent_clock_emulation();
|
2010-08-04 02:34:48 +08:00
|
|
|
|
2017-11-02 20:07:02 +08:00
|
|
|
set_normalized_timespec64(ts, nsecs / NSEC_PER_SEC,
|
|
|
|
nsecs % NSEC_PER_SEC);
|
2010-07-14 08:56:24 +08:00
|
|
|
}
|
|
|
|
|
2007-10-16 16:27:24 +08:00
|
|
|
void __init time_init(void)
|
2006-07-10 19:45:05 +08:00
|
|
|
{
|
2015-11-03 00:16:37 +08:00
|
|
|
timer_set_signal_handler();
|
2017-09-29 16:07:44 +08:00
|
|
|
late_time_init = um_timer_setup;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2019-05-27 16:34:27 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_UML_TIME_TRAVEL_SUPPORT
|
|
|
|
unsigned long calibrate_delay_is_known(void)
|
|
|
|
{
|
2020-02-13 21:26:47 +08:00
|
|
|
if (time_travel_mode == TT_MODE_INFCPU ||
|
|
|
|
time_travel_mode == TT_MODE_EXTERNAL)
|
2019-05-27 16:34:27 +08:00
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int setup_time_travel(char *str)
|
|
|
|
{
|
|
|
|
if (strcmp(str, "=inf-cpu") == 0) {
|
|
|
|
time_travel_mode = TT_MODE_INFCPU;
|
|
|
|
timer_clockevent.name = "time-travel-timer-infcpu";
|
|
|
|
timer_clocksource.name = "time-travel-clock";
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2020-02-13 21:26:47 +08:00
|
|
|
if (strncmp(str, "=ext:", 5) == 0) {
|
|
|
|
time_travel_mode = TT_MODE_EXTERNAL;
|
|
|
|
timer_clockevent.name = "time-travel-timer-external";
|
|
|
|
timer_clocksource.name = "time-travel-clock-external";
|
|
|
|
return time_travel_connect_external(str + 5);
|
|
|
|
}
|
|
|
|
|
2019-05-27 16:34:27 +08:00
|
|
|
if (!*str) {
|
|
|
|
time_travel_mode = TT_MODE_BASIC;
|
|
|
|
timer_clockevent.name = "time-travel-timer";
|
|
|
|
timer_clocksource.name = "time-travel-clock";
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
__setup("time-travel", setup_time_travel);
|
|
|
|
__uml_help(setup_time_travel,
|
|
|
|
"time-travel\n"
|
|
|
|
"This option just enables basic time travel mode, in which the clock/timers\n"
|
|
|
|
"inside the UML instance skip forward when there's nothing to do, rather than\n"
|
|
|
|
"waiting for real time to elapse. However, instance CPU speed is limited by\n"
|
|
|
|
"the real CPU speed, so e.g. a 10ms timer will always fire after ~10ms wall\n"
|
|
|
|
"clock (but quicker when there's nothing to do).\n"
|
|
|
|
"\n"
|
|
|
|
"time-travel=inf-cpu\n"
|
|
|
|
"This enables time travel mode with infinite processing power, in which there\n"
|
|
|
|
"are no wall clock timers, and any CPU processing happens - as seen from the\n"
|
|
|
|
"guest - instantly. This can be useful for accurate simulation regardless of\n"
|
|
|
|
"debug overhead, physical CPU speed, etc. but is somewhat dangerous as it can\n"
|
2020-02-13 21:26:47 +08:00
|
|
|
"easily lead to getting stuck (e.g. if anything in the system busy loops).\n"
|
|
|
|
"\n"
|
|
|
|
"time-travel=ext:[ID:]/path/to/socket\n"
|
|
|
|
"This enables time travel mode similar to =inf-cpu, except the system will\n"
|
|
|
|
"use the given socket to coordinate with a central scheduler, in order to\n"
|
|
|
|
"have more than one system simultaneously be on simulated time. The virtio\n"
|
|
|
|
"driver code in UML knows about this so you can also simulate networks and\n"
|
|
|
|
"devices using it, assuming the device has the right capabilities.\n"
|
|
|
|
"The optional ID is a 64-bit integer that's sent to the central scheduler.\n");
|
2019-05-27 16:34:27 +08:00
|
|
|
|
|
|
|
int setup_time_travel_start(char *str)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = kstrtoull(str, 0, &time_travel_start);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
time_travel_start_set = 1;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
__setup("time-travel-start", setup_time_travel_start);
|
|
|
|
__uml_help(setup_time_travel_start,
|
|
|
|
"time-travel-start=<seconds>\n"
|
|
|
|
"Configure the UML instance's wall clock to start at this value rather than\n"
|
|
|
|
"the host's wall clock at the time of UML boot.\n");
|
|
|
|
#endif
|