From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NvB1E-0007JK-H9 for qemu-devel@nongnu.org; Fri, 26 Mar 2010 11:00:16 -0400 Received: from [140.186.70.92] (port=40775 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NvB0H-0006wy-QL for qemu-devel@nongnu.org; Fri, 26 Mar 2010 11:00:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NvB00-0005Ia-Ea for qemu-devel@nongnu.org; Fri, 26 Mar 2010 10:59:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34546) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NvB00-0005IO-4g for qemu-devel@nongnu.org; Fri, 26 Mar 2010 10:59:00 -0400 Date: Fri, 26 Mar 2010 20:27:28 +0530 From: Amit Shah Subject: Re: [Qemu-devel] Re: [PATCH 10/15] virtio-serial: Add QMP events for failed port/device add Message-ID: <20100326145728.GH7039@amit-x200.redhat.com> References: <20100324173415.63e31bd0@redhat.com> <20100325034717.GA23562@amit-x200.redhat.com> <20100325153406.69fbc717@redhat.com> <20100326011749.GE19308@shareable.org> <20100326020752.GH8111@amit-x200.redhat.com> <20100326040754.GU19308@shareable.org> <20100326045607.GJ8111@amit-x200.redhat.com> <20100326052325.GZ19308@shareable.org> <20100326134936.GF7039@amit-x200.redhat.com> <20100326144423.GA11626@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100326144423.GA11626@shareable.org> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Luiz Capitulino , "Michael S. Tsirkin" , Gerd Hoffmann , qemu list , Juan Quintela 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