From owner-freebsd-virtualization@freebsd.org Mon Jul 11 22:17:13 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 BD1D4B92822 for ; Mon, 11 Jul 2016 22:17:13 +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 829E71236 for ; Mon, 11 Jul 2016 22:17:13 +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 <0OA60071I8KN4K30@mta.uoks.uj.edu.pl> for freebsd-virtualization@freebsd.org; Tue, 12 Jul 2016 00:17:12 +0200 (CEST) Subject: Re: [Differential] D7185: Add virtio-console support to bhyve From: Jakub Klama In-reply-to: <57841572.7060903@redbarn.org> Date: Tue, 12 Jul 2016 00:17:11 +0200 Cc: freebsd-virtualization@freebsd.org Content-transfer-encoding: quoted-printable Message-id: <577FFDDF-7EC5-4143-AA1B-858BA8C3287F@uj.edu.pl> 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> 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: Mon, 11 Jul 2016 22:17:13 -0000 > Wiadomo=C5=9B=C4=87 napisana przez Paul Vixie w = dniu 11.07.2016, o godz. 23:53: >=20 >=20 >=20 > Jakub Klama wrote: >> nmdm(4) emulates a serial port. how could one pass ioctls and signals = via serial port? >=20 > 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. >=20 > rtty would have to do the same. That's the plan, but obviously it won't work with nmdm(4). bhyve could = also allocate a pty/pts, retrieve it's name using ptsname() and report = that back to the user. >=20 >>> yikes. so you've got to reinvent what TIOCPKT does, but differently? >>=20 >> how could one pass ioctls via unix domain socket? >=20 > you can't. that's why i'm saying "but differently". >=20 > [...] > 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. >=20 Host-side handling of window size change is pretty much straightforward, = so there's nothing to discuss here. Propagating the window size values = to the guest happens via resize event defined in virtio-console = specification. Guest kernel and guest virtio-console driver performs = whatever is necessary to handle that event. > 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. 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. 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. Jakub=