From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34410) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzABv-0003bN-Os for qemu-devel@nongnu.org; Tue, 25 Oct 2016 18:27:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzABu-0006Cw-O8 for qemu-devel@nongnu.org; Tue, 25 Oct 2016 18:27:31 -0400 Received: from mail-yw0-x235.google.com ([2607:f8b0:4002:c05::235]:33546) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bzABu-0006Ck-JV for qemu-devel@nongnu.org; Tue, 25 Oct 2016 18:27:30 -0400 Received: by mail-yw0-x235.google.com with SMTP id t192so22295295ywf.0 for ; Tue, 25 Oct 2016 15:27:30 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Stefan Hajnoczi Date: Tue, 25 Oct 2016 23:27:29 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] qemu-ga virtio-serial socket clarification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Matt Broadstone Cc: qemu-devel , Michael Roth On Tue, Oct 25, 2016 at 7:14 PM, Matt Broadstone wrote: > I've been attempting an experimental qemu agent using a node.js daemon on > the host side, and have run into an issue I was hoping someone here might > be able to help with: > > Using libvirt I've set up a 'unix' channel for a domain using virtio-serial > (the same way you would for the existing qemu agent) with the name > 'test.agent', in order to bypass libvirt taking ownership of the domain > socket. This works as expected, and so does the following test: > > - [host] $ echo "testing" | nc -U > /var/lib/libvirt/qemu/channel/target/domain-T40001/test.agent > - [guest] $ cat -v < /dev/virtio-ports/test.agent > > Then I tried the same test, converting the host->guest communication to > node.js: > > 'use strict'; > const net = require('net'); > const socketPath = > '/var/lib/libvirt/qemu/channel/target/domain-T40001/test.agent'; > let socket = net.createConnection(socketPath); > socket.write('testing'); > > In this case the data makes it across to the guest, however until I > explicitly close the socket on the sender side (`socket.write('testing', () > => socket.end())`) both sides block indefinitely. I understand closing the > socket brings the node example to parity with the netcat one, however after > perusing the qemu-ga and libvirt repositories it looks like glib's io > channels are being used on a single socket, and effectively handling > bidirectional data. > > Is this the expected behavior? > > This would seem to imply that normal async communication over the domain > socket is somehow different in the virtio-serial case (as in I can't > maintain a duplex socket, but would rather have to juggle opening and > closing read/write sockets). In my research I came across another similar > project: https://github.com/xolox/python-negotiator, which requires two > channels: one for host->guest communication, and another for guest->host > communication, likely because of this very issue. virtio-serial is full-duplex. Please post the receive side test program you are using. Stefan