On Mon, Sep 09, 2019 at 07:34:24PM +0200, Johannes Berg wrote:
> On Mon, 2019-09-09 at 18:00 +0200, Stefan Hajnoczi wrote:
> 
> > Is this really necessary?  
> 
> Yes* :)
> 
> > Can the simulation interpose between the
> > call/kick eventfds in order to control when events happen?
> > 
> >   CPU --cpu_kickfd--> Simulation --vhost_kickfd--> vhost-user device
> > 
> > and:
> > 
> >   vhost-user device --vhost_callfd--> Simulation -->cpu_callfd-> CPU
> > 
> > The simluation controls when the CPU's kick is seen by the device and
> > also when the call is seen by the CPU.
> 
> The point isn't to let the simulation know about anything that happens.
> The CPU and the device are *part* of the simulation.

I was thinking more of letting the simulation decide when to signal the
second eventfd in each pair, but now I understand you are trying to make
everything synchronous and ioeventfd is async by definition.

> 
> > I don't understand why new vhost-user protocol messages are required.
> 
> I guess I haven't really explained it well then :-)
> 
> So let's say, WLOG, I have a simulated network and a bunch of Linux
> machines that are running on simulation time. Today I can do that only
> with user-mode Linux, but we'll see.
> 
> Now in order to run everything on simulation time, *everything* that
> happens in the simulation needs to request a simulation calendar entry,
> and gets told when that entry is scheduled.
> 
> So think, for example, you have
> 
> CPU ---[kick]---> device
> 
> Now, this is essentially triggering an interrupt in the device. However,
> the simulation code has to ensure that the simulated device's interrupt
> handling only happens at a scheduler entry. Fundamentally, the
> simulation serializes all processing, contrary to what you want in a
> real system.
> 
> Now, this means that the CPU (that's part of the simulation) has to
> *wait* for the device to add an entry to the simulation calendar in
> response to the kick... That means that it really has to look like
> 
> CPU               device                   calendar
>      ---[kick]-->
>                          ---[add entry]-->
>                          <---[return]-----

What are the semantics of returning from the calendar?  Does it mean
"it's now your turn to run?", "your entry has been added and you'll be
notified later when it's time to run?", or something else?

>      <-[return]--

What are the semantics of returning to the CPU?  Does it mean the
submitted I/O request is now complete?

> 
> so that the CPU won't get to idle or some other processing where it asks
> the simulation calendar for its own next entry...
>
> Yes, like I said before, I realize that all of this is completely
> opposed to what you want in a real system, but then in a real system you
> also have real timeouts, and don't just skip time forward when the
> simulation calendar says so ...

Sorry for these questions.  If this becomes tedious for you I will look
into the paper you linked.

Stefan