From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nv9wM-0007JH-Si for qemu-devel@nongnu.org; Fri, 26 Mar 2010 09:51:10 -0400 Received: from [140.186.70.92] (port=58489 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nv9wL-0007J9-Go for qemu-devel@nongnu.org; Fri, 26 Mar 2010 09:51:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nv9wJ-0004cn-Oo for qemu-devel@nongnu.org; Fri, 26 Mar 2010 09:51:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20313) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nv9wJ-0004ce-F2 for qemu-devel@nongnu.org; Fri, 26 Mar 2010 09:51:07 -0400 Date: Fri, 26 Mar 2010 19:19:36 +0530 From: Amit Shah Subject: Re: [Qemu-devel] Re: [PATCH 10/15] virtio-serial: Add QMP events for failed port/device add Message-ID: <20100326134936.GF7039@amit-x200.redhat.com> References: <1269442173-18421-10-git-send-email-amit.shah@redhat.com> <1269442173-18421-11-git-send-email-amit.shah@redhat.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100326052325.GZ19308@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 [05:23:25], Jamie Lokier wrote: > 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. 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. > 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. > 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. Yeah; that's some state to maintain -- and I'm not sure we should do that. If we start adding some state now, we could end up adding more later, and it could soon become a mess. Amit