[PATCH 1/4] um: irqs: process outstanding IRQs when unblocking signals

[Benjamin Beichler]

Am 20.10.2023 um 11:26 schrieb Anton Ivanov:

>> 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.
> 
There is already mechanics for it, as we have um_request_irq_tt and 
um_request_irq. I don't think an additional type enhance the semantics.


>>
>> 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?
>>