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

[Johannes Berg]

On Fri, 2023-10-20 at 14:43 +0200, Benjamin Beichler wrote:
> > > Yes but you need to schedule for the interrupt, and you don't
> > > necessarily know what 'current time' is at interrupt time.
> > > 
> > > So let's say you have "something" that's scheduled to run at times
> > >   - 1000
> > >   - 2000
> > >   - 3000
> > > 
> > > and free-until is 10000 or something high.
> > > 
> > It can also happen without free-until, then it just depends which one of
> > the two - they're running in parallel now (linux doing time-travel
> > interrupt handling and adding the event, the other thing continuing to
> > schedule and doing the next entry)  - asks the controller first.
> 
> Since they happen at the same time, most discrete event simulations make 
> the assumption, that the actual order of execution should not be part of 
> the semantics.
> 

Well, fair, but they can bounce more messages around them, and that
should change things. I don't think we've built a simulation system here
that can strictly assume this is true.

In any case, it can get worse - if he sender process actually updated
the controller to 2000 by the time the linux actually calls
time_travel_add_irq_event(), the linux event will run at 2000 instead of
1000.

All this is why we have the vhost-user extensions for ACK messages etc.

johannes