Am 10.11.2023 um 18:16 schrieb Johannes Berg:
________________________________
On Fri, 2023-11-10 at 17:53 +0100, Benjamin Beichler wrote:
At least in my mental model this is broken because the sender of the
event basically has to prepare the calendar for it happening, which
feels ... odd.
Actually, for me, this would make kind of sense.
I'm not sure I agree, I guess. To me, the sender is just telling someone
else "here's something going on I want you to look at". That doesn't
really mean the receiver needs to actually handle it "right away". Maybe
the receiver implements a model where it's modelling an interrupt
latency (which _would_ be more realistic), so it only handles the
message some (small amount of) time later. Maybe it's in a polling model
right now and has disabled interrupt sources, and just wakes every so
often to check for messages. Maybe something else.
So I don't really agree that baking a "must be scheduled immediately"
into any protocol really makes sense.
I think you are mixing here some levels of abstraction. Some entity in
the "system" needs to
react to an interrupt immediately. In the real world, this is mostly
done by some kind of interrupt controller
which may latch the interrupt (if they are deactivated from CPU side).
Of course some more sophisticated
bus protocols (i.e. virtio/vhost in this case) can also signal the
device to do no interrupts, but in the most
basic case, e.g. a button at a GPIO pin, the device could not handle
that. Most of the interrupt abstraction
in um is realized via signals, but some more seems (IMHO) to be needed
from the tt-protocol, if we have external
device simulations. My suggestion was to add the virtual interrupt line
state change as a message to the calendar.
Of course, you could argue, that the device simulation needs to be
clever enough (so distributing this task of the
interrupt controller), but even therefore the device simulation need
some more information to reflect delayed interrupts,
deactivated interrupts and so on.
What confuses me is, that you explicitly use the immediate synchronous
response model on the interrupts from the vhost/virtio
driver, but you seem to refuse this on other drivers.
Why couldn't we be more
explicit in the time travel protocol to the calendar about interrupts?
We could use the ID from the start-msg to identify um instances and
tell, in an additional msg, that we are going to trigger an interrupt at
the current time to that instance from the device simulation.
But see above - I basically just don't think the sender of the event is
the right position to know that information.
Mhh if I apply that to the vhost/virtio simulations, that is, what is
implicitly modeled by
the exchanged file descriptors and vhost/virtio protocol state.
We may change the whole tt-ext-mode to only accept vhost/virtio drivers,
but that needs to
be stated explicitly in the documentation. I'm not really in favor of
that, but if it is documented
it is easier to understand.
Another way would be, to serve such information (if the device
simulation really need it) over the facilities we already established.
Why not send the ACK as MSG_OOB or ancillary data?
Don't think I understand that. Which "facilities" are you referring to
here?
I hadn't researched that on Friday, but we could use a custom control
msg (cmsg) on the unix sockets
attached to the (serial) line devices. The device simulation can then
wait on that ancillary data for
synchronous interrupt handling, as you have proposed for vhost/virtio.
My first idea was to use
MSG_OOB, which do not exit on Unix-Domain-Sockets. If someone does not
use uds as transport
we may give a warning.
Benjamin
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
