[PATCH RFC 03/11] um: Use a simple time travel handler for line interrupts

[Benjamin Beichler]

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