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