From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6LhJ-0003pd-Ex for qemu-devel@nongnu.org; Tue, 08 Dec 2015 12:05:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a6LhF-0000LO-So for qemu-devel@nongnu.org; Tue, 08 Dec 2015 12:05:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49534) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6LhF-0000KO-L2 for qemu-devel@nongnu.org; Tue, 08 Dec 2015 12:05:01 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id BD144859F8 for ; Tue, 8 Dec 2015 17:05:00 +0000 (UTC) References: <20151208145944.GP2999@redhat.com> From: Eric Blake Message-ID: <56670DB7.8050306@redhat.com> Date: Tue, 8 Dec 2015 10:04:55 -0700 MIME-Version: 1.0 In-Reply-To: <20151208145944.GP2999@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NrWuDg6rMa0xpvde12Vu3QdbapXQUqkQs" Subject: Re: [Qemu-devel] FD passing for chardevs and chardev backend multiplexing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org Cc: libvir-list@redhat.com, Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NrWuDg6rMa0xpvde12Vu3QdbapXQUqkQs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/08/2015 07:59 AM, Daniel P. Berrange wrote: > So for this my plan is to stop using the QEMU 'file' backend for char > devs and instead pass across a pre-opened file descriptor, connected > to virtlogd. There is no "officially documented" way to pass in a > file descriptor to QEMU chardevs, but since QEMU uses qemu_open(), > we can make use of the fdset feature to achieve this. eg >=20 > eg, consider fd 33 is the write end of a pipe file descriptor > I can (in theory) do >=20 > -add-fd set=3D2,fd=3D33 -chardev file,id=3Dcharserial0,path=3D/dev/fd= set/2 >=20 > Now in practice this doesn't work, because qmp_chardev_open_file() > passes the O_CREAT|O_TRUNC flags in, which means the qemu_open() > call will fail when using the pipe FD pased in via fdsets. Is it just the O_TRUNC that is failing? If so, there is a recent patch to add an 'append':true flag that switches O_TRUNC off in favor of O_APPE= ND: https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg00762.html Or is it that the pipe is one-way, but chardev insists on O_RDWR and fails because it is not two-way? >=20 > After more investigation I found it *is* possible to use a socketpair > and a pipe backend though... >=20 > -add-fd set=3D2,fd=3D33 -chardev pipe,id=3Dcharserial0,path=3D/dev/fd= set/2 Yes, a socketpair is bi-directional, so it supports O_RDWR opening. >=20 > ..because for reasons I don't understand, if QEMU can't open $PATH.in > and $PATH.out, it'll fallback to just opening $PATH in read-write > mode even. AFAICT, this is pretty useless with pipes since they > are unidirectional, but, it works nicely with socketpairs, where > virtlogd has one of the socketpairs and QEMU gets passed the other > via fdset. Is it something where we'd want to support two pipes, and open /dev/fdset/2 tied to char.in and /dev/fdset/3 tied to char.out, where uni-directional pipes are again okay? >=20 > I can easily check this works for historical QEMU versions back > to when fdsets support was added to chardevs, but I'm working if > the QEMU maintainers consider this usage acceptable over the long > term, and if so, should we explicitly document it as supported ? It seems like a bi-directional socketpair as the single endpoint for a chardev is useful enough to support and document, but I'm not the maintainer to give final say-so. >=20 > If not, should we introduce a more explicit syntax for passing in > a pre-opened FD for chardevs ? eg >=20 > -add-fd set=3D2,fd=3D33 -chardev fd,id=3Dcharserial0,path=3D/dev/fdse= t/2 >=20 Difference to the line you tried above: > -add-fd set=3D2,fd=3D33 -chardev file,id=3Dcharserial0,path=3D/dev/fd= set/2 is 'fd' instead of 'file'. But if we're going to add a new protocol, do we even need to go through the "/dev/fdset/..." name, or can we just pass the fd number directly? > Or just make -chardev file,id=3Dcharserial0,path=3D/dev/fdset/2 actual= ly > work ? I'd lean more to this case - the whole point of fdsets was that we don't have to add multiple fd protocols; that everyone that understood file syntax and uses qemu_open() magically gained fd support. >=20 > Or something else ? >=20 >=20 > OpenStack has a further requirement to allow use of the serial port > as an interactive console, at the same time that it is logging to a > file which is something QEMU can't support at all currently. This > essentially means being able to have multiple chardev backends all > connected to the same serial frontend - specifically we would need > a TCP backend and a file backend concurrently. Again this could be > implemented in QEMU, but we'd prefer something that works with > existing QEMU. >=20 > This is not too difficult to achieve with virtlogd really. Instead > of using the QEMU 'tcp' or 'unix' chardev protocol, we'd just always > pass QEMU a pre-opened socketpair, and then leave the TCP/UNIX > socket listening to the virtlogd daemon. >=20 > This is portable with existing QEMU versions, but the obvious downside > with this is extra copies in the interactive console path. So might it > be worth exploring the posibility of a chardev multiplexor in QEMU. We > would still pass in a pre-opened socketpair to QEMU for the logging sid= e > of things, but would leave the TCP/UNIX socket listening upto QEMU stil= l. >=20 > eg should we make something like this work: >=20 > -add-fd set=3D2,fd=3D33 > -chardev pipe,id=3Dcharserial0file,path=3D/dev/fdset/2 > -chardev socket,id=3Dcharserial0tcp,host=3D127.0.0.1,port=3D9999,teln= et,server,nowait > -chardev multiplex,id=3Dcharserial0,muxA=3Dcharserial0file,muxB=3Dcha= rserial1 wouldn't muxB be charserial0tcp (not charserial1)? > -serial isa-serial,chardev=3Dcharserial0,id=3Dserial0 But the idea of a multiplex protocol that has multiple data sinks (guest output copied to all sinks) and a single source (at most one source can provide input to the guest) makes sense on the surface. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --NrWuDg6rMa0xpvde12Vu3QdbapXQUqkQs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWZw23AAoJEKeha0olJ0NqYWMH+wegeyz0xhe/00IvByIGt84I XoILHRRP76XAL5d2lAOQb7MfyHCcTmiFACg17pbCP2/8ZrAVsrlQMA8Jxo5wmJYS qkUkwMPFwQpO0Ake30/4OaxE0mm5TOOGQxidPYZDHN4L6AAQRCwVugIHf4eduGiz 7WxVSkPFO/pkoC2bDunagiNlgQvu2pt7tIel/wYEQR/JFd5COcal3/ZaWyiWoswU dzcj7fqby65e6uenAvEQ7pOuLordXjI4j3nfxMy3HyoW4p5GaxYxj7UhNJbaL6EU HSRkZkYSkcheiEJ39MEZqJOLQXPTvDfLaU9Z6q2eg8uVzfMWDHVtCveexOAzjZA= =qZ1h -----END PGP SIGNATURE----- --NrWuDg6rMa0xpvde12Vu3QdbapXQUqkQs--