From owner-freebsd-virtualization@freebsd.org Mon Jul 11 21:53:57 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 73A01B92168 for ; Mon, 11 Jul 2016 21:53:57 +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 565AB13C3 for ; Mon, 11 Jul 2016 21:53:57 +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 506C73AF8E; Mon, 11 Jul 2016 21:53:56 +0000 (UTC) Message-ID: <57841572.7060903@redbarn.org> Date: Mon, 11 Jul 2016 14:53:54 -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> In-Reply-To: <6B5AEBF8-98B0-4031-A3E3-A1EBC8B4B763@uj.edu.pl> 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: Mon, 11 Jul 2016 21:53:57 -0000 Jakub Klama wrote: > nmdm(4) emulates a serial port. how could one pass ioctls and signals via serial port? i think if bhyve arranged for its virtio_console device to be its control terminal, it would receive SIGWINCH from the host kernel, which it could propagate to the guest's /dev/console, after first doing a TIOCGWINSZ to find the new size and making that available to the guest's /dev/console driver's TIOCGWINSZ. rtty would have to do the same. >> yikes. so you've got to reinvent what TIOCPKT does, but differently? > > how could one pass ioctls via unix domain socket? you can't. that's why i'm saying "but differently". so what's supposed to happen is that a window size event is propagated through a tty-like device (nmdm, pty, pts) by setting the new window size with TIOCSWINSZ and then causing the process group of the control tty to receive a SIGWINCH, which receives the new window size with TIOCGWINSZ. this works on pty and pts, because the software that connects the master and slave sides of those pseudo terminal devices is window size aware. in sys/kern/tty_pts.c we see the following: /* Just redirect this ioctl to the slave device. */ tty_lock(tp); error = tty_ioctl(tp, cmd, data, fp->f_flag, td); tty_unlock(tp); if (error == ENOIOCTL) error = ENOTTY; this is after a switch statement that fails to enumerate TIOCSWINSZ, so it falls through to this code in sys/kern/tty.c: case TIOCGWINSZ: /* Obtain window size. */ *(struct winsize*)data = tp->t_winsize; return (0); case TIOCSWINSZ: /* Set window size. */ tty_set_winsize(tp, data); return (0); ssh (slogin), rlogin, telnet, but sadly not rtty, all catch SIGWINCH, then they do TIOCGWINSZ to retrieve the kernel's idea of new window size, then they propagate this to their other-side (sshd, rlogind, telnetd) using a control-packet that's unique to each protocol. the other-side hears the control message and calls TIOCSWINSZ to tell the other-side kernel about the new window size. when this happens, the code shown above for TIOCSWINSZ that calls tty_set_winsize() causes the SIGWINCH to be sent to the process group of the tty: void tty_set_winsize(struct tty *tp, const struct winsize *wsz) { if (memcmp(&tp->t_winsize, wsz, sizeof(*wsz)) == 0) return; tp->t_winsize = *wsz; tty_signal_pgrp(tp, SIGWINCH); } so in the bhyve case, the bhyve process and its console driver is acting as both a tty client (because it connects to one in the host) and as a tty server (because it offers one in the guest), and it is therefore in the role that rlogin+rlogind, or telnet+telnetd, or ssh+sshd, would be in. and in that role, you hear SIGWINCH, you ask for TIOCGWINSZ, you propagate this value in an implementation-dependent way, and you perform the effect of TIOCSWINSZ to your guest. so, i still don't understand why you created a vertio_console driver that opens a socket in the host file system and speaks a new protocol over that. you can, from within bhyve, do what rlogin+rlogind, or ssh+sshd, or telnet+telnetd do. if nmdm isn't propagating window size changes yet, either you or i can fix that. and i can fix rtty. inventing a new data path with a new (and as-yet-undefined) protocol should be a last resort. we're no where near last-resort yet. -- P Vixie