From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55489 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsFpp-00072h-3B for qemu-devel@nongnu.org; Wed, 23 Feb 2011 09:36:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PsFpl-000596-ES for qemu-devel@nongnu.org; Wed, 23 Feb 2011 09:36:54 -0500 Received: from e5.ny.us.ibm.com ([32.97.182.145]:42411) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PsFpl-000592-Ag for qemu-devel@nongnu.org; Wed, 23 Feb 2011 09:36:53 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1NECPEL024280 for ; Wed, 23 Feb 2011 09:12:25 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1NEaqQ9126000 for ; Wed, 23 Feb 2011 09:36:52 -0500 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p1NEapIo016390 for ; Wed, 23 Feb 2011 07:36:51 -0700 Message-ID: <4D651B81.9000201@linux.vnet.ibm.com> Date: Wed, 23 Feb 2011 08:36:49 -0600 From: Michael Roth MIME-Version: 1.0 References: <4D643B77.60109@linux.vnet.ibm.com> <20110223045944.GA9886@amit-x200.redhat.com> <4D651A58.6060606@linux.vnet.ibm.com> In-Reply-To: <4D651A58.6060606@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: virtio-serial semantics for binary data and guest agents List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah Cc: Anthony Liguori , "qemu-devel@nongnu.org Developers" , Adam Litke On 02/23/2011 08:31 AM, Michael Roth wrote: > On 02/22/2011 10:59 PM, Amit Shah wrote: >> On (Tue) 22 Feb 2011 [16:40:55], Michael Roth wrote: >>> If something in the guest is attempting to read/write from the >>> virtio-serial device, and nothing is connected to virtio-serial's >>> host character device (say, a socket) >>> >>> 1. writes will block until something connect()s, at which point the >>> write will succeed >>> >>> 2. reads will always return 0 until something connect()s, at which >>> point the reads will block until there's data >>> >>> This makes it difficult (impossible?) to implement the notion of >>> connect/disconnect or open/close over virtio-serial without layering >>> another protocol on top using hackish things like length-encoded >>> payloads or sentinel values to determine the end of one >>> RPC/request/response/session and the start of the next. >>> >>> For instance, if the host side disconnects, then reconnects before >>> we read(), we may never get the read()=0, and our FD remains valid. >>> Whereas with a tcp/unix socket our FD is no longer valid, and the >>> read()=0 is an event we can check for at any point after the other >>> end does a close/disconnect. >> >> There's SIGIO support, so host connect-disconnect notifications can be >> caught via the signal. > > I recall looking into this at some point....but don't we get a SIGIO for > read/write-ability in general? So you still need some way differentiate, > say, readability from a disconnect/EOF, and the read()=0 that could > determine this is still racing with host-side reconnects. > >> >> Also, nonblocking reads/writes will return -EPIPE if the host-side >> connection is not up. > > But we still essentially need to poll() for a host-side disconnected heh, just "poll" not poll() sorry > state, which is still racy since they may reconnect before we've done a > read/write that would've generated the -EPIPE. It seems like what we > really need is for the FD to be invalid from that point forward. > > Also, I focused more on the guest-side connect/disconnect detection, but > as Anthony mentioned I think the host side shares similar limitations as > well. AFAIK once we connect to the chardev that FD remains valid until > the connected process closes it, and so races with the guest side on > detecting connect/disconnect events in a similar manner. For the host > side it looks like virtio-console has guest_close/guest_open callbacks > already that we could potentially use...seems like it's just a matter of > tying them to the chardev... basically having virtio-serial's > guest_close() result in a close() on the corresponding chardev > connection's FD. > >> >> Amit >