On 20/10/2023 10:15, Benjamin Beichler wrote:
Am 18.10.2023 um 14:36 schrieb benja...@sipsolutions.net:
From: Benjamin Berg <benjamin.b...@intel.com>
When in time-travel mode, the eventfd events are read even when signals
are blocked as SIGIO still needs to be processed. In this case, the
event is cleared on the eventfd but the IRQ still needs to be fired
later.
We did already ensure that the SIGIO handler is run again. However, the
FDs are configured to be level triggered, so that eventfd will not
notify again. As such, add some logic to mark the IRQ as pending and
process it at the next opportunity.
To avoid duplication, reuse the logic used for the suspend/resume case.
This does not really change anything except for delaying running the
IRQs with timetravel_handler at a slightly later point in time (and
possibly running non-timetravel IRQs that shouldn't happen earlier).
While at it, move marking as pending into irq_event_handler as that is
the more logical place for it to happen.
Signed-off-by: Benjamin Berg <benjamin.b...@intel.com>
I also noticed this problem, but after a discussion with Johannes Berg about
this, we come to the conclusion, that all drivers with interrupts need to deal
with time travel mode via their own time travel handler. What I actually did,
was to write a trivial handler for e.g., the serial line, which simply only
call time_travel_add_irq_event(ev).
I'm not entirely sure, what the right way to do it, although the outcome seems
to be the same, as with no time advance the actual simulation time, when the
interrupt is handled is the same.
Add an extra registration flag for um_register_irq?
enum um_irq_type {
IRQ_READ,
IRQ_WRITE,
IRQ_HAVE_TT_HANDLER,
NUM_IRQ_TYPES,
};
Ones that do not register get the default one which advances the time. Ones
that do - have it left to them and do with time whatever they need.
I actually also have some other significant bug fixes on time travel in my
tree, but I was too lazy to send them here, are you interested in taking a look
at them?
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
--
Anton R. Ivanov
https://www.kot-begemot.co.uk/
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um