From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47337 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ps1Ml-00013u-OP for qemu-devel@nongnu.org; Tue, 22 Feb 2011 18:10:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ps1Mk-0005gc-Ib for qemu-devel@nongnu.org; Tue, 22 Feb 2011 18:09:59 -0500 Received: from e8.ny.us.ibm.com ([32.97.182.138]:48776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ps1Mk-0005g2-GH for qemu-devel@nongnu.org; Tue, 22 Feb 2011 18:09:58 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1MIpKnE005840 for ; Tue, 22 Feb 2011 13:51:20 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1MN9soJ198580 for ; Tue, 22 Feb 2011 18:09:54 -0500 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p1MN9sQW023948 for ; Tue, 22 Feb 2011 16:09:54 -0700 Message-ID: <4D644246.8010309@linux.vnet.ibm.com> Date: Tue, 22 Feb 2011 17:09:58 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4D643B77.60109@linux.vnet.ibm.com> In-Reply-To: <4D643B77.60109@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: Michael Roth Cc: Amit Shah , "qemu-devel@nongnu.org Developers" , Adam Litke My basic understanding here is--there's no way for a virtio-serial client (in-guest) to reliably reset a session such that if the client in the guest crashes, the protocol needs to have some recovery mechanism. This seems like a huge oversight in the design of virtio-serial. Are we missing something here? Regards, Anthony Liguori On 02/22/2011 04:40 PM, Michael Roth wrote: > Hi everyone, > > As some of you are aware we've been working for a few months now > towards creating a qemu-specific guest agent to implement > bi-directional RPCs between the host and the guest to support certain > operations like copy/paste, guest-initiated shutdown, and basic file > transfer. > > Currently the protocol uses the xmlrpc-c library to marshall functions > and arguments into a data format we can transport over > virtio-serial/isa-serial via an HTTP-like protocol. Recently some > concerns have been raised over pulling an external dependency such as > xmlrpc-c into qemu, and we've been looking at some alternatives. > > Some clear, well-defined approaches such as ASN.1/BER show much > promise, but we currently lack a way to implement them cleanly due to > the following drawbacks with virtio-serial which prevent us from being > able to implement connection/session-oriented protocols: > > 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. > > Or if the host side disconnects/closes before/while we write(), we > block. If they reconnect, our write() succeeds, and they potentially > end up with garbage meant for the previous process. With a tcp/unix > socket, the write() will return an EPIPE indicating the FD is no > longer valid. > > Since virtio-serial is meant to be a general-purpose transport for raw > binary data as well as a pv serial console, I wonder if a > virtio-serial mode with semantics closer to tcp/unix sockets is > necessary? Any thoughts? > > Thanks, > > Mike