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

[Benjamin Beichler]

Am 20.10.2023 um 13:39 schrieb Johannes Berg:
> On Fri, 2023-10-20 at 12:38 +0200, Benjamin Beichler wrote:
>>
>> Can you explain, why a time travel handler for stdin may be bad? It
>> sounds like you want to avoid it, but I see no immediate problem.
>>
> 
> I need to read the thread, but this one's easy ;-)
> 
> The thing is that on such a channel you don't send an ACK when you've
> seen that there's something to handle. As a result, the sender will
> continue running while you're trying to request a new schedule entry
> from the controller. As a result, it may run past your new schedule
> entry because it didn't know about it yet (this would likely bring down
> the controller and crash the simulation), or the relative order of the
> two entries is undefined, in the sense that it depends on the process
> scheduling of the host.
Sorry, but I did not get this. What may run past the schedule entry? Is 
your assumption, that the "thing" connected to stdin is always totally 
unaware of the time travel mode?

When our (to be published) simulation send something on serial lines (I 
think it does not matter whether it is a socket or a pipe), we expect 
that the uml instance needs to be run as long as it changes back to 
idle/wait state before the simulation time is advanced. Since the basis 
model of the time travel mode is, that you have infinite amount of 
processing power, the interrupt needs to be always handled at the 
current time.

Maybe my think-model only holds for "smaller" amounts of data (maybe one 
page or something?) or not the free-running mode, but I'm not completely 
convinced. :-D

Maybe we need to define, a bit more formally, how the (designed) 
processing model of interrupts in time travel mode is.

> 
> johannes
> 
> _______________________________________________
> linux-um mailing list
> linux-um at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-um

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1569BBF90AC3918A.asc
Type: application/pgp-keys
Size: 2976 bytes
Desc: OpenPGP public key
URL: <http://lists.infradead.org/pipermail/linux-um/attachments/20231020/d2e72a93/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-um/attachments/20231020/d2e72a93/attachment.sig>