On (Fri) Mar 26 2010 [14:44:23], Jamie Lokier wrote:
> 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.
You did? Well, then we agree on a solution :-)
> > > 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.
Which means the qemu chardev. Is it smart enough? Dunno.
> I don't think that 1 bit state ("open" or "closed") is too much to
> carry around in migration etc.
If the app sits inside qemu then maintaining open/close isn't a problem
at all. In fact, guest and host open/closed state is already maintained
by virtio-serial.
> > > 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 :-)
I agree. So: ports have in-qemu users, they get guest_open /
guest_close callbacks and get data which they can pass on to external
apps. Looks like we're fine there?
> *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.
Amit
