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

[Johannes Berg]

On Fri, 2023-10-20 at 17:47 +0200, Benjamin Beichler wrote:
> 
> I think, I get now, why I don't have this Problem: My virtio simulation 
> and my controller/simulation-master are tightly coupled and indeed the 
> same process. When I create a new event for the UML-instance, it is 
> anticipated in the simulation master.
> 
> So my sequence is more like:
> B sends message to A's stdin (say at 1000)
> B tells the controller, that it activated A, and time should not advance 
> until A has sent a request for processing an interrupt and has gone back 
> to waiting state
> B requests to run at 2000 from controller
> B releases time to controller
> ...

Ahh, OK. I thought you were probably using our controller from the
usfstl, but of course you don't have to. I think I did push the shared
memory optimisation there though, but I suspect I haven't posted the
Linux client version.

> I see that without further information from the device simulation to the 
> controller, it is quite harder.

Right, I wanted to handle that in the other side (hence the ACK) since
you might not always know _when_ the interrupt is scheduled there, even
if it's currently always "immediately".

> Nonetheless, I'm not totally sure, how this interacts with the timing 
> semantics of the interrupts here. Either the solution of Benjamin Berg 
> or mine (with the trivial tt-handler have the same problem).

Oh, yeah, his changes do have the same problem. He's just fixing that
interrupts got lost completely in some already _otherwise_ broken cases,
to make it work better without hanging, not to make it work correctly.

To make it work correctly you shouldn't use stdio at all, or I guess
have some external helper thing like you do :)

johannes