Re: [Qemu-devel] Re: [PATCH 10/15] virtio-serial: Add QMP events for failed port/device add

[Amit Shah]

On (Fri) Mar 26 2010 [05:23:25], Jamie Lokier wrote:
> Amit Shah wrote:
> > > Sure.  Does the host app see an EOF on its input when that happens?
> > > (I.e. *not* like a real serial port).
> > 
> > If it's an in-qemu app, it gets the guest_closed() callback. So I guess
> > qmp events for non-qemu apps is what you're looking for?
> 
> See below.
> 
> > > But what I really meant was, if the guest resets, and then it boots up
> > > before the host apps manage to process their events (e.g. due to
> > > timing, remoteness, swapping or whatever), it's important that the
> > > virtio-serial using host app knows where the discontinuity in the byte
> > > stream is.  Otherwise the app needs to use a silly overcomplicated
> > > protocol just to provide a reliable layer over the byte stream.
> > 
> > I'd rather that the apps used the existing QMP notifications for guest
> > reset so that we don't have to do anything special for virtio-serial
> > (and for other devices as well).
> 
> I'm trying to understand how to avoid the race condition with that.
> 
> 1. guest sends a big blob of data to virtio-serial
> 2. qemu writes to socket for host app
>       -> wakes up host app (outside qemu) listening for virtio-serial data
> 3. guest resets or its kernel crashes
>       -> the big blob is only partially sent
> 4. qemu sends QMP notification
> 5.    -> wakes up host app listening for QMP events
> 6. guest boots up.
> 7. guest opens virtio-serial, and starts by sending a message.
> 8.    -> host app gets to run, sees the event sent in step 2.
> 9.    -> host app reads available data from virtio-serial
>          data includes bytes sent in step 1 and step 7
> 
> Can the host app tell which bytes to discard because they were a
> truncated message sent prior to the reset, so that it can find the
> start of the new message sent in step 7?
> 
> A QMP event has that race condition.

Problem is we're going to have to maintain a lot of state if we're going
to provide guarantees.

One solution is to always have an in-qemu user of the serial
functionality that sits between the app and the guest and the in-qemu
user can signal to the app about such things.

> If communication with the external host app is over a local socket
> (AF_UNIX or AF_INET or mkpipe), qemu could just disconnect and
> reconnect whenever the guest does, which is perfectly logical and
> solves this.

The virtio-serial code cannot know what kind of a connection it has with
the host app.

> If the external host app is fork+exec'd from qemu with a pair of pipes
> (",exec="), closing the writing pipe, waiting for EOF from the
> reading pipe, and then re-exec-ing the external app would do as well.
> 
> If neither of those are used, then a bit more context from QMP is
> needed, such as the exact number of bytes transmitted prior to the
> reset, presumably in a virtio-serial close event.

Yeah; that's some state to maintain -- and I'm not sure we should do
that. If we start adding some state now, we could end up adding more
later, and it could soon become a mess.

                Amit