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 _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um
