From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43098 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsFl3-0004F9-V6 for qemu-devel@nongnu.org; Wed, 23 Feb 2011 09:32:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PsFl2-0004DO-QM for qemu-devel@nongnu.org; Wed, 23 Feb 2011 09:32:01 -0500 Received: from e9.ny.us.ibm.com ([32.97.182.139]:60111) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PsFl2-0004DJ-Mq for qemu-devel@nongnu.org; Wed, 23 Feb 2011 09:32:00 -0500 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1NE6COw017337 for ; Wed, 23 Feb 2011 09:06:12 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1NEVxSB2695270 for ; Wed, 23 Feb 2011 09:31:59 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p1NEVwVg000481 for ; Wed, 23 Feb 2011 09:31:58 -0500 Message-ID: <4D651A58.6060606@linux.vnet.ibm.com> Date: Wed, 23 Feb 2011 08:31:52 -0600 From: Michael Roth MIME-Version: 1.0 References: <4D643B77.60109@linux.vnet.ibm.com> <20110223045944.GA9886@amit-x200.redhat.com> In-Reply-To: <20110223045944.GA9886@amit-x200.redhat.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/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 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