From: Johannes Berg <johannes@sipsolutions.net>
To: Benjamin Beichler <Benjamin.Beichler@uni-rostock.de>,
linux-um@lists.infradead.org
Subject: Re: [PATCH 1/4] um: irqs: process outstanding IRQs when unblocking signals
Date: Fri, 20 Oct 2023 17:51:43 +0200 [thread overview]
Message-ID: <6622572d97b970bc83ac628a8b6c93f91f0bdf2e.camel@sipsolutions.net> (raw)
In-Reply-To: <fe6dc227-44f4-466e-a99b-e5e9e6afe7aa@uni-rostock.de>
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
prev parent reply other threads:[~2023-10-20 15:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 12:36 [PATCH 1/4] um: irqs: process outstanding IRQs when unblocking signals benjamin
2023-10-18 12:36 ` [PATCH 2/4] um: chan_user: catch EINTR when reading and writing benjamin
2023-10-18 12:36 ` [PATCH 3/4] um: chan_user: retry partial writes benjamin
2023-10-18 12:36 ` [PATCH 4/4] um: chan: use blocking IO for console output for time-travel benjamin
2023-10-20 9:15 ` [PATCH 1/4] um: irqs: process outstanding IRQs when unblocking signals Benjamin Beichler
2023-10-20 9:26 ` Anton Ivanov
2023-10-20 10:33 ` Benjamin Beichler
2023-10-20 9:59 ` Benjamin Berg
2023-10-20 10:38 ` Benjamin Beichler
2023-10-20 11:39 ` Johannes Berg
2023-10-20 12:06 ` Benjamin Beichler
2023-10-20 12:20 ` Johannes Berg
2023-10-20 12:23 ` Johannes Berg
2023-10-20 12:43 ` Benjamin Beichler
2023-10-20 12:58 ` Johannes Berg
2023-10-20 12:58 ` Benjamin Beichler
2023-10-20 13:39 ` Johannes Berg
2023-10-20 15:47 ` Benjamin Beichler
2023-10-20 15:51 ` Johannes Berg [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6622572d97b970bc83ac628a8b6c93f91f0bdf2e.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=Benjamin.Beichler@uni-rostock.de \
--cc=linux-um@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).