From owner-freebsd-virtualization@freebsd.org Tue Jul 12 08:19:31 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 DBD91B929CA for ; Tue, 12 Jul 2016 08:19:31 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B89392E74 for ; Tue, 12 Jul 2016 08:19:31 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from [24.104.150.22] (unknown [24.104.150.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 584AE3AF43; Tue, 12 Jul 2016 06:25:19 +0000 (UTC) Message-ID: <57848D4D.8040906@redbarn.org> Date: Mon, 11 Jul 2016 23:25:17 -0700 From: Paul Vixie User-Agent: Postbox 4.0.8 (Windows/20151105) MIME-Version: 1.0 To: Jakub Klama CC: freebsd-virtualization@freebsd.org Subject: Re: [Differential] D7185: Add virtio-console support to bhyve 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 08:19:32 -0000 Jakub Klama wrote: >> 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. >> > > Well, it *can* be a tty to the host, but doesn't need to be. that's madness. i'd like bhyve to remain for all time as clean as it is now. so if you want a flat clean bidirectional channel for your "guest additions" on the guest to talk to your "middleware" on the host, that's fine by me, but don't let either end look like a tty to anybody. in fact, it would be better for bhyve for you to implement both host and guest drivers for virtio_vsock than to use the non-tty features of virtio_console. > 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. your initial mention of resize events up-thread gets harder and harder for me to understand as we continue down-thread. please don't implement "console" ports at all unless the host side of such a port has to talk to a pts, pty, or nmdm. separately, let's work together to get TIOC{S|G}WINSZ support working in nmdm. this means, please don't let a guest tty talk to a host unix-domain socket that has to have a second control channel for carrying tty events like window size. just don't do that. make the guest tty talk to a host nmdm, pty, or pts. > 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? generally you let all the pts/pty/nmdm devices have the same pgrp and when you get a SIGWINCH you poll all of your devices with TIOCGWINSZ. the SIGWINCH event is rare enough and the number of devices is low enough that this polling is not a performance problem. > * It doesn't necessarily need to be connected to bhyve process > stdin/stdout bhyve should never connect its stdin/stdout to the guest. that's bad design. let's work together to stamp it out, starting by never letting any of your virtio_console ports (should you implement the kind that appear to the guest as tty devices) to bhyve stdin/stdout. > * If bhyve opens pty(s), how would it communicate ptsname() back to > the user? that would be a fine thing to send to stdout at bhyve initialization time. >> 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. > > 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. if you say "we will never multiplex the unix domain socket" and you say "pts, pty, or nmdm" rather than "pseudo tty", then we're in agreement. > 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. i would prefer to see this as a virtio_vsock. thank you for explaining. -- P Vixie