From owner-freebsd-virtualization@freebsd.org Tue Jul 12 01:16:29 2016 Return-Path: Delivered-To: freebsd-virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDF16B835F2 for ; Tue, 12 Jul 2016 01:16:29 +0000 (UTC) (envelope-from jakub.klama@uj.edu.pl) Received: from mail1.uj.edu.pl (mail1.uj.edu.pl [149.156.89.193]) by mx1.freebsd.org (Postfix) with ESMTP id A3B1713C4 for ; Tue, 12 Jul 2016 01:16:29 +0000 (UTC) (envelope-from jakub.klama@uj.edu.pl) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [192.168.0.2] ([89.70.28.46]) by mta.uoks.uj.edu.pl (Oracle Communications Messaging Server 7u4-27.01 (7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0OA600317GVF1I00@mta.uoks.uj.edu.pl> for freebsd-virtualization@freebsd.org; Tue, 12 Jul 2016 03:16:28 +0200 (CEST) Subject: Re: [Differential] D7185: Add virtio-console support to bhyve From: Jakub Klama In-reply-to: <57843C3D.80102@redbarn.org> Date: Tue, 12 Jul 2016 03:16:27 +0200 Cc: freebsd-virtualization@freebsd.org Content-transfer-encoding: quoted-printable Message-id: References: <5783D6FF.7010107@redbarn.org> <5783E2FE.1040309@redbarn.org> <5783E64B.9010608@redbarn.org> <6B5AEBF8-98B0-4031-A3E3-A1EBC8B4B763@uj.edu.pl> <57841572.7060903@redbarn.org> <577FFDDF-7EC5-4143-AA1B-858BA8C3287F@uj.edu.pl> <57843C3D.80102@redbarn.org> To: Paul Vixie X-Mailer: Apple Mail (2.3094) X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 01:16:30 -0000 > Wiadomo=C5=9B=C4=87 napisana przez Paul Vixie w = dniu 12.07.2016, o godz. 02:39: >=20 > Jakub Klama wrote: >=20 >> It doesn't speak any protocol. virtio-console is a pipe. it pushes >> bytes back and forth. Name is indeed unfortunate, it should have >> been called virtio-pipe, but virtio-console is how the virtio >> specification calls it. >=20 > if it's never going to appear as /dev/console or any other tty-like > device to the guest, then i won't care what it looks like on the host. > however, you said it could carry resize events, which leads me to > believe that the name (vertio-console) is not wrong, and it is a tty = to the guest, and in my view that means it should be a tty to the host. >=20 Well, it *can* be a tty to the host, but doesn't need to be. Driver = supports multiple ports, and every port can be marked as a "console" = port. Linux guests create regular character devices for "normal" = virtio-console ports and ttys for "console" ports. My code doesn't = support "console" ports yet at all. I agree that the console port should be a tty on the host. But there are = some things to consider: * There can be more than one - how do we receive resize events from = every pty? polling? fork per pty? * It doesn't necessarily need to be connected to bhyve process = stdin/stdout * If bhyve opens pty(s), how would it communicate ptsname() back to the = user? > please explain how your proposed addition to bhyve handles resize = events but is not actually related to tty use by either the guest or = host. >=20 It doesn't, that's just not supported yet :) >> If we were to use virtio-console as a system console, then using a >> pseudo tty and forwarding pty resize notifications as resize control >> events to the guest is totally fine and desired (at least as one of >> the options). However, as I said, unix domain socket is perfect fit >> for using is at a regular bidirectional pipe. >=20 > if that pipe has resize events encoded in it, as you said earlier, = then it has to have a protocol, and it is not just a bidirectional pipe. >=20 Pipe itself doesn't have resize events. Resize events are transmitted = out of band, in a separate control queue. That out of band communication = is not visible to the unix domain socket consumer. It could be made = visible in two ways: a) by implementing multiplexing in the unix domain = socket protocol b) by using pseudo tty, connecting pty data stream to = the pipe and handing resizes separately. > please explain more about your use case. what will this device look = like to the guest, and what application do you expect to have running on = the host to talk to this unix domain socket? We're using it in freenas-vm-tools, a "guest additions" package that = would allow host-guest interactions, such as automatic mounting of the = shared 9P storage when being added in the hypervisor GUI, synchronizing = time, potentially also suspending the I/O while snapshotting the VM = datasets, and so on. In the guest, virtio-console is visible as a = regular character device (/dev/virtio-ports/org.freenas.vm-tools). On = the host side, FreeNAS 10 middleware talks to it. Jakub=