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

[Jamie Lokier <jamie@shareable.org>]

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.

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.

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.

-- Jamie