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:
> 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.

Isn't that what I suggested?  I don't mind how the app is signalled.
I'm just thinking of the simplest way to do it.  It doesn't have to
live in the virtio-serial driver, just be signalled somehow out of it.

> > 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.

True, but the qemu internal plumbing could pass an open/close event to
that connection handler, for it to do whatever's appropriate.

I don't think that 1 bit state ("open" or "closed") is too much to
carry around in migration etc.

> > 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.

I'd rather not count bytes anyway.  That smacks too much of
maintaining long term history. I'd rather it was 1 bit of state, and
the host app connection handler able to use it.

> If we start adding some state now, we could end up adding more
> later, and it could soon become a mess.

Each thing ought to be weighed on its merits.

Without this specific thing, which is an indicator that guest has lost
state outside its control, the guest<->host communication is
unreliable (even for things like "cut and paste"), so every app that
cares has to implement a packet framing protocol with no binary data
(to reserve an escaping byte), or with CRCs like
PPP-over-virtio-serial, which is complicated and silly imho.  If it
were a real serial port, not emulated, that's the sort of thing apps
would actually do (or use timeouts, which are more dubious in
emulator-land).  But I hope we're not that sadistic :-)

*Inband* open/close indication aren't 100% guarantees of reliability,
but I think they raise it to the point where an app can usefully count
on it.

-- Jamie