From owner-freebsd-virtualization@freebsd.org Sun Jul 10 01:10:35 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 1DAE6B83489 for ; Sun, 10 Jul 2016 01:10:35 +0000 (UTC) (envelope-from fabian.freyer@physik.tu-berlin.de) Received: from mail.tu-berlin.de (mail.tu-berlin.de [130.149.7.33]) (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 CFD2B1C65 for ; Sun, 10 Jul 2016 01:10:34 +0000 (UTC) (envelope-from fabian.freyer@physik.tu-berlin.de) X-tubIT-Incoming-IP: 130.149.50.25 Received: from mail.physik-pool.tu-berlin.de ([130.149.50.25] helo=mail.physik.tu-berlin.de) by mail.tu-berlin.de (exim-4.84_2/mailfrontend-8) with esmtp id 1bM3GR-00072u-mM; Sun, 10 Jul 2016 03:10:33 +0200 Received: from monster.turm11.org (x4d06a19b.dyn.telefonica.de [77.6.161.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.physik.tu-berlin.de (Postfix) with ESMTPSA id 1E62B57A4; Sun, 10 Jul 2016 01:10:22 +0000 (UTC) Subject: Re: new ports for UEFI firmware To: freebsd-virtualization@freebsd.org References: <0d17b666-84c1-2864-e94b-6af7dc02dfd9@physik.tu-berlin.de> Cc: Roman Bogorodskiy , Michael Dexter From: Fabian Freyer Message-ID: <7ccb03f9-e06b-6860-6b0a-ebe1065a0c24@physik.tu-berlin.de> Date: Sun, 10 Jul 2016 03:10:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <0d17b666-84c1-2864-e94b-6af7dc02dfd9@physik.tu-berlin.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tMkVSuQueI8WPitXOnT7VnGspVHAaFCUX" 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: Sun, 10 Jul 2016 01:10:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tMkVSuQueI8WPitXOnT7VnGspVHAaFCUX Content-Type: multipart/mixed; boundary="3tLo12EPKWrCJHjhhjbXELTncPGMPkuPN" From: Fabian Freyer To: freebsd-virtualization@freebsd.org Cc: Roman Bogorodskiy , Michael Dexter Message-ID: <7ccb03f9-e06b-6860-6b0a-ebe1065a0c24@physik.tu-berlin.de> Subject: Re: new ports for UEFI firmware References: <0d17b666-84c1-2864-e94b-6af7dc02dfd9@physik.tu-berlin.de> In-Reply-To: <0d17b666-84c1-2864-e94b-6af7dc02dfd9@physik.tu-berlin.de> --3tLo12EPKWrCJHjhhjbXELTncPGMPkuPN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, there are now two ports: sysutils/uefi-edk2-bhyve sysutils/uefi-edk2-bhyve-csm which build with and without CSM built in, to enable both CSM and non-CSM= firmwares to be installed in parallel. The firmwares are both installed to /usr/local/share/uefi-firmware/. Thanks to Roman Bogorodskiy for creating the slave port and Michael Dexte= r for providing feedback on the original port. Fabian --3tLo12EPKWrCJHjhhjbXELTncPGMPkuPN-- --tMkVSuQueI8WPitXOnT7VnGspVHAaFCUX 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 iQIcBAEBCAAGBQJXgaB9AAoJEDlu9CkMwdG7KZcP/Rt8bdfzQfsJksq6MWNn5Mnb B+Vem8zZ28inMt+mIA2Lju5WxrCIvZ0pHdNghPDfsyYsP6j/LCfceamfxSQdfYUW +Gd0wYCQCA3te6Jm0TdhwGJTd+fnXVesEMc5/FZBOYOPyNNY6pNX9Pk2kIi/WM4A IbIwkPqkkeeTFJ0JCASDu2AjRUh3qKv7TV5z9MJq3iOOlmLtGPNya/cvDqyn4znR ECgw6wooSYdiGiFolCBs73hRpbFugrVr26k2Dx8DiP9+76Ctjz06g2AbciUmjpMa ZmV5WpojZ3I+2dAh/9PZZqYSz407PB/CRibREYcQkfIh29EamW16+Lxf6E4fLfIL CLrb/nco1KJk5xh7P67mHE8MCFyM1gp/P9qUXWbGf4ZTAVmJNK9RRcCXL4Ax7uIx SeUfave4f8Rxgmt+oITddjgI2blxHfaO9vGmghgXmu6jNr68LK2rp+M2J6URkxcb oMRq9okNHVj+T0jn7RMydrjUaE9yyZGPXccdEh6/7WYyyKuYfpPXDXwYJOYyDoE8 5g68AKuHu3+PGtSjgN8CH4jPYrMlSNaU4BZCsW5jkcYqVxiTa4j4quAC5gqKfNqe Fz2PvTK93FzAimImts9FM6lC/HAGKpLEMinxZwJcpBVOxz4abqmqBFYKpro2hM/2 Ay1DvoZ/TwxMiLaanMFq =UB+i -----END PGP SIGNATURE----- --tMkVSuQueI8WPitXOnT7VnGspVHAaFCUX-- From owner-freebsd-virtualization@freebsd.org Sun Jul 10 10:32:08 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 CF181B8476E for ; Sun, 10 Jul 2016 10:32:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 BEDC9122B for ; Sun, 10 Jul 2016 10:32:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u6AAW8Mu063732 for ; Sun, 10 Jul 2016 10:32:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-virtualization@FreeBSD.org Subject: [Bug 209392] Panic on FreeBSD guest on bhyve Date: Sun, 10 Jul 2016 10:32:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pkubaj@anongoth.pl X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-virtualization@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 10 Jul 2016 10:32:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209392 --- Comment #4 from Piotr Kubaj --- (In reply to Peter Grehan from comment #3) Sorry, for the (very) late answer, I guess I just accidentally removed the email from BZ. Nope, there was no other process in the background. It was a VM set up specifically as a testing environment for my ports, so it didn't have anyth= ing besides the base system. Also, I've even compiled Android on Debian VM (wit= h 16 vCPU), so at least Linux doesn't have this problem. ALSO, I have since upgraded my server to head (now running 11.0-ALPHA5) and= the problem seems to be gone. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-virtualization@freebsd.org Mon Jul 11 06:33:07 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 5E58FB9152C for ; Mon, 11 Jul 2016 06:33:07 +0000 (UTC) (envelope-from no-reply@x6.vip.6pm-coupon.com) Received: from x6.vip.6pm-coupon.com (x6.vip.6pm-coupon.com [104.148.25.6]) by mx1.freebsd.org (Postfix) with ESMTP id 4DB7D1662 for ; Mon, 11 Jul 2016 06:33:06 +0000 (UTC) (envelope-from no-reply@x6.vip.6pm-coupon.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=6pm-coupon; d=x6.vip.6pm-coupon.com; h=MIME-Version:From:To:Date:Subject:Content-Type:Content-Transfer-Encoding; i=no-reply@x6.vip.6pm-coupon.com; bh=WEK4gUxmGlHGpfvuiLCpo9zKBag=; b=Sfbep7VtoFZ49qt1QLQaxufldqKg23g9acXmAvmZhlLkabb1PZs+Q5ZUvUAqCQZPIUSOlsckVSsO zIprY92tZkZSHXWJJAnQuG93rwnUWNYMZbKeywFcFcLTqRgVUvE5tVvww/gS6QzR/mSDeryKsPRt ng/ITkPKkvWhkcfyVMs= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=6pm-coupon; d=x6.vip.6pm-coupon.com; b=fhLKubQp0T9f/nn18+Gev0PIx2sWyuK5LYzjNwAEoThr2XvxXbHA1hYsQBbOoteQpfTj0OpQMUFX UM3JC3qjufakuUsvKbqrAy7NoW1R/Mye4WjzhkVWBYZaczM0HKf2tuaXwTy3V/Ujfrctyn54Qnlz KL+CYuB+PzTRnD77U9o=; From: "Ray.Ban Sunglasses" To: freebsd-virtualization@freebsd.org Date: 11 Jul 2016 14:22:51 +0800 Subject: No Joke:Your great offer and Free Shipping from Factory549 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 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 06:33:07 -0000 From owner-freebsd-virtualization@freebsd.org Mon Jul 11 09:39:41 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 94918B83935 for ; Mon, 11 Jul 2016 09:39:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 769A11B25 for ; Mon, 11 Jul 2016 09:39:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u6B9dfk2049846 for ; Mon, 11 Jul 2016 09:39:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-virtualization@FreeBSD.org Subject: [Bug 208241] [Hyper-V] VM network may not work over virtual switch based on wireless NIC Date: Mon, 11 Jul 2016 09:39:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: decui@microsoft.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Works As Intended X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-virtualization@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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 09:39:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208241 Dexuan Cui changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Works As Intended Status|New |Closed CC| |decui@microsoft.com --- Comment #1 from Dexuan Cui --- The real cause of the issue should exist in the Hyper-V host side and it's unlikely to get this fixed in the near future considering the effort needed= and its priority, as far as I can tell. And since we have an effective workaround (see the original description whe= n I reported the bug), let me close the bug -- I chose "Works As Intended" beca= use I couldn't find a better type like "WON'T FIX". Feel free to correct this, = if you know how to do it. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-virtualization@freebsd.org Mon Jul 11 09:55:04 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 1AA11B83F5E for ; Mon, 11 Jul 2016 09:55:04 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 00AFF164C for ; Mon, 11 Jul 2016 09:55:04 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: by mailman.ysv.freebsd.org (Postfix) id F0801B83F5D; Mon, 11 Jul 2016 09:55:03 +0000 (UTC) Delivered-To: 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 F01C6B83F5C for ; Mon, 11 Jul 2016 09:55:03 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "0x20.net", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6BF2164A; Mon, 11 Jul 2016 09:55:03 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 20C596E0081; Mon, 11 Jul 2016 11:55:00 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id u6B9sxsT091154; Mon, 11 Jul 2016 11:54:59 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id u6B9sxFV090459; Mon, 11 Jul 2016 11:54:59 +0200 (CEST) (envelope-from lars) Date: Mon, 11 Jul 2016 11:54:59 +0200 From: Lars Engels To: Peter Grehan Cc: virtualization@freebsd.org Subject: Re: bhyve coredump on 11.0-ALPHA6 Message-ID: <20160711095459.GE15808@e-new.0x20.net> References: <20160709202256.GV15808@e-new.0x20.net> <20160709202622.GW15808@e-new.0x20.net> <82055769-cd25-63cd-aa70-bf2a5c238668@freebsd.org> <20160709214151.GZ15808@e-new.0x20.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PZgnm7T+MVPmWSUE" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) 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 09:55:04 -0000 --PZgnm7T+MVPmWSUE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 09, 2016 at 02:46:32PM -0700, Peter Grehan wrote: > > Yes, without that line it boots. But the vnc cursor speed does not match > > the host cursor speed. >=20 > That's the classic problem with VNC - most o/s's implement cursor=20 > acceleration, while VNC only reports absolute cursor position, and the=20 > ps2 mouse only reports relative cursor position :( >=20 > The advantage of the usb tablet is that it reports absolute position,= =20 > so the VNC and rendered cursor are identical. Agitate on FreeBSD support= =20 > for that :) I know. Now if someone could implement this... ;-) --PZgnm7T+MVPmWSUE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJXg2zzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1t+MUH+wfm2Up0GaQ7BOnFzKwjN8tc pvV/2FL2cBl2wQQIvgdGTnUNAzzr33WxRjr61LICG514qBQYisHf8G3jkCs30JR4 /jMbOSkICO5avSzNiHxGoodtnqiF7vptAv8ucIbvNId+ShqlEWtYy7jVj+FzUly0 CPZgQvFWrSl47Jh4V/YktQovcWl+mBUbOQRGFfuuZOD8NPv8rJDWNN6fyVzIu2A8 qczdoV0e+S8eSn3lUfOhIHnouvCDQgSBZbCaMsFATfoVtvDuR+N1otK393/s7lZm c18QPHKZv3zy4UAVgSljUicW8i+hSkUQ6az8Az5hisX9+zjVAhqvUJB7EuE5PCA= =tFDL -----END PGP SIGNATURE----- --PZgnm7T+MVPmWSUE-- From owner-freebsd-virtualization@freebsd.org Mon Jul 11 10:06:23 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 DB927B84706 for ; Mon, 11 Jul 2016 10:06:23 +0000 (UTC) (envelope-from no-reply@x55.vip.6pm-coupon.com) Received: from x55.vip.6pm-coupon.com (x55.vip.6pm-coupon.com [104.148.25.55]) by mx1.freebsd.org (Postfix) with ESMTP id 826FB1C57 for ; Mon, 11 Jul 2016 10:06:21 +0000 (UTC) (envelope-from no-reply@x55.vip.6pm-coupon.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=6pm-coupon; d=x55.vip.6pm-coupon.com; h=MIME-Version:From:To:Date:Subject:Content-Type:Content-Transfer-Encoding; i=no-reply@x55.vip.6pm-coupon.com; bh=5ySv11WBYIgOQJL+EXlrIZLsUtI=; b=hW8duf+9zCoEh/rCQGekaOkHlXKnnqpzjwIhgHUiFZaLpmxHaqnO2FhtwOO7U4qwX14tgGHoPxD7 RU0TPeBf/bp40IkYU+1EC2nKWsdTj9MpsR9BHnqyKNuxGPUKMB2ktzpKEim9C2gWeqkwQOXIpxDL 0hDwR4OqcM4fbLkpCK4= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=6pm-coupon; d=x55.vip.6pm-coupon.com; b=rVOHTQFNNXhjHLrDNIRTSlkI+ABq366jhx6UUpMRFHN/yDq4JUwr87EkkIlK/1b6ftgZ/AaqfCv0 orONMGv6iWqTebLs4HYaPinoHScfhqVNlkgt6yK2Dr9D7443fBKkmMAhUDLV85hiLAyJyBbgqhYj EHCGtaIRd5RcQB6zaEs=; From: "Ray.Ban Sunglasses" To: freebsd-virtualization@freebsd.org Date: 11 Jul 2016 17:46:03 +0800 Subject: Notice:72 Hours Only, Don't Miss Out!876 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 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 10:06:24 -0000 From owner-freebsd-virtualization@freebsd.org Mon Jul 11 13:19:23 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 24284B838E4 for ; Mon, 11 Jul 2016 13:19:23 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id E2E0C16FE for ; Mon, 11 Jul 2016 13:19:22 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id A3C0A161D; Mon, 11 Jul 2016 13:19:22 +0000 (UTC) Date: Mon, 11 Jul 2016 13:19:22 +0000 To: freebsd-virtualization@freebsd.org From: "jceel (Jakub Klama)" Reply-to: D7185+333+7754cf487cff2162@reviews.freebsd.org Subject: [Differential] D7185: Add virtio-console support to bhyve Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , Thread-Topic: D7185: Add virtio-console support to bhyve X-Herald-Rules: <28> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk Thread-Index: MjhlZGRiYzhlY2RmMDVlMjRhODI2ZDZhMGU4 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_a323306a2e70d59516842eb696491cc6" X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.22 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 13:19:23 -0000 --b1_a323306a2e70d59516842eb696491cc6 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: base64 amNlZWwgY3JlYXRlZCB0aGlzIHJldmlzaW9uLgpqY2VlbCBhZGRlZCByZXZpZXdlcnM6IGdyZWhh biwgdHJhc3ouCmpjZWVsIGFkZGVkIGEgc3Vic2NyaWJlcjogZnJlZWJzZC12aXJ0dWFsaXphdGlv bi1saXN0LgpqY2VlbCBzZXQgdGhlIHJlcG9zaXRvcnkgZm9yIHRoaXMgcmV2aXNpb24gdG8gclMg RnJlZUJTRCBzcmMgcmVwb3NpdG9yeS4KSGVyYWxkIGFkZGVkIGEgc3Vic2NyaWJlcjogaW1wLgoK UkVWSVNJT04gU1VNTUFSWQogIEFkZHMgdmlydGlvLWNvbnNvbGUgZGV2aWNlIHN1cHBvcnQgdG8g Ymh5dmUsIGFsbG93aW5nIHRvIGNyZWF0ZSBiaWRpcmVjdGlvbmFsIGNoYXJhY3RlciBzdHJlYW1z IGJldHdlZW4gaG9zdCBhbmQgZ3Vlc3QuCiAgCiAgU3ludGF4OgogIGAtcyA8c2xvdG51bT4sdmly dGlvLWNvbnNvbGUscG9ydDE9L3BhdGgvdG8vcG9ydDEuc29jayxwb3J0Mj0vcGF0aC90by9wb3J0 Mi5zb2NrLC4uLmAKICAKICBNYXhpbXVtIG9mIDE2IHBvcnRzIHBlciBkZXZpY2UgY2FuIGJlIGNy ZWF0ZWQuIEV2ZXJ5IHBvcnQgaXMgbmFtZWQgYW5kIGNvcnJlc3BvbmRzIHRvIGFuIFVuaXggZG9t YWluIHNvY2tldCBjcmVhdGVkIGJ5IGJoeXZlLiBiaHl2ZSBhY2NlcHRzIGF0IG1vc3Qgb25lIHVu aXggZG9tYWluIHNvY2tldCBjb25uZWN0aW9uIHBlciBwb3J0IGF0IGEgdGltZS4KICAKICBMaW1p dGF0aW9uczoKICAKICAtIGR1ZSB0byBsYWNrIG9mIGRlc3RydWN0b3JzIG9mIGluIGJoeXZlLCBz b2NrZXRzIG9uIHRoZSBmaWxlc3lzdGVtIG11c3QgYmUgY2xlYW5lZCB1cCBtYW51YWxseSBhZnRl ciBiaHl2ZSBleGl0cwogIC0gdGhlcmUncyBubyB3YXkgdG8gdXNlICJjb25zb2xlIHBvcnQiIGZl YXR1cmUsIG5vciB0aGUgY29uc29sZSBwb3J0IHJlc2l6ZSBhcyBvZiB5ZXQKICAtIGVtZXJnZW5j eSB3cml0ZSBpcyBhZHZlcnRpc2VkLCBidXQgbm8tb3AgYXMgb2YgeWV0CgpURVNUIFBMQU4KICBT dGFydCBGcmVlQlNEIGd1ZXN0IGluIGJoeXZlIHdpdGggYC1zIDksdmlydGlvLWNvbnNvbGUsdGVz dHBvcnQ9L3RtcC90ZXN0cG9ydC5zb2NrYC4gVHlwZSBga2xkbG9hZCB2aXJ0aW9fY29uc29sZWAg aW4gdGhlIGd1ZXN0LCB0aGVuIGBjdSAtbCAvZGV2L3R0eVYwLjBgIGluIHRoZSBndWVzdCBhbmQg YHNvY2F0IC0gL3RtcC90ZXN0cG9ydC5zb2NrYCBpbiB0aGUgaG9zdC4KClJFUE9TSVRPUlkKICBy UyBGcmVlQlNEIHNyYyByZXBvc2l0b3J5CgpSRVZJU0lPTiBERVRBSUwKICBodHRwczovL3Jldmll d3MuZnJlZWJzZC5vcmcvRDcxODUKCkFGRkVDVEVEIEZJTEVTCiAgdXNyLnNiaW4vYmh5dmUvTWFr ZWZpbGUKICB1c3Iuc2Jpbi9iaHl2ZS9wY2lfdmlydGlvX2NvbnNvbGUuYwogIHVzci5zYmluL2Jo eXZlL3ZpcnRpby5oCgpFTUFJTCBQUkVGRVJFTkNFUwogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNk Lm9yZy9zZXR0aW5ncy9wYW5lbC9lbWFpbHByZWZlcmVuY2VzLwoKVG86IGpjZWVsLCBncmVoYW4s IHRyYXN6CkNjOiBpbXAsIGZyZWVic2QtdmlydHVhbGl6YXRpb24tbGlzdAo= --b1_a323306a2e70d59516842eb696491cc6 Content-Type: text/x-patch; charset=utf-8; name="D7185.18284.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D7185.18284.patch" ZGlmZiAtLWdpdCBhL3Vzci5zYmluL2JoeXZlL3ZpcnRpby5oIGIvdXNyLnNiaW4vYmh5dmUvdmly dGlvLmgKLS0tIGEvdXNyLnNiaW4vYmh5dmUvdmlydGlvLmgKKysrIGIvdXNyLnNiaW4vYmh5dmUv dmlydGlvLmgKQEAgLTIxMCw2ICsyMTAsNyBAQAogI2RlZmluZQlWSVJUSU9fREVWX05FVAkJMHgx MDAwCiAjZGVmaW5lCVZJUlRJT19ERVZfQkxPQ0sJMHgxMDAxCiAjZGVmaW5lCVZJUlRJT19ERVZf UkFORE9NCTB4MTAwMgorI2RlZmluZQlWSVJUSU9fREVWX0NPTlNPTEUJMHgxMDAzCiAKIC8qCiAg KiBQQ0kgY29uZmlnIHNwYWNlIGNvbnN0YW50cy4KZGlmZiAtLWdpdCBhL3Vzci5zYmluL2JoeXZl L3BjaV92aXJ0aW9fY29uc29sZS5jIGIvdXNyLnNiaW4vYmh5dmUvcGNpX3ZpcnRpb19jb25zb2xl LmMKLS0tIGEvdXNyLnNiaW4vYmh5dmUvcGNpX3ZpcnRpb19jb25zb2xlLmMKKysrIGIvdXNyLnNi aW4vYmh5dmUvcGNpX3ZpcnRpb19jb25zb2xlLmMKQEAgLTAsMCArMSw2MzEgQEAKKy8qLQorICog Q29weXJpZ2h0IChjKSAyMDE2IGlYc3lzdGVtcyBJbmMuCisgKiBBbGwgcmlnaHRzIHJlc2VydmVk LgorICoKKyAqIFRoaXMgc29mdHdhcmUgd2FzIGRldmVsb3BlZCBieSBKYWt1YiBLbGFtYSA8amNl ZWxARnJlZUJTRC5vcmc+CisgKiB1bmRlciBzcG9uc29yc2hpcCBmcm9tIGlYc3lzdGVtcyBJbmMu CisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jt cywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlk ZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRp c3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdo dAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2lu ZyBkaXNjbGFpbWVyCisgKiAgICBpbiB0aGlzIHBvc2l0aW9uIGFuZCB1bmNoYW5nZWQuCisgKiAy LiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3Zl IGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhl IGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Ig b3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBU SElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBg YEFTIElTJycgQU5ECisgKiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xV RElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBN RVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBB UkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVU T1JTIEJFIExJQUJMRQorICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBT UEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElO RywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisg KiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNT IElOVEVSUlVQVElPTikKKyAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJ QUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRP UlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZ CisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0Yg VEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqLworCisjaW5jbHVkZSA8c3lz L2NkZWZzLmg+CitfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CisKKyNpbmNsdWRlIDxzeXMvcGFyYW0u aD4KKyNpbmNsdWRlIDxzeXMvbGlua2VyX3NldC5oPgorI2luY2x1ZGUgPHN5cy91aW8uaD4KKyNp bmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRlIDxzeXMvc29ja2V0Lmg+CisjaW5jbHVkZSA8 c3lzL3VuLmg+CisKKyNpbmNsdWRlIDxlcnJuby5oPgorI2luY2x1ZGUgPGZjbnRsLmg+CisjaW5j bHVkZSA8c3RkaW8uaD4KKyNpbmNsdWRlIDxzdGRsaWIuaD4KKyNpbmNsdWRlIDxzdGRib29sLmg+ CisjaW5jbHVkZSA8c3RyaW5nLmg+CisjaW5jbHVkZSA8dW5pc3RkLmg+CisjaW5jbHVkZSA8YXNz ZXJ0Lmg+CisjaW5jbHVkZSA8cHRocmVhZC5oPgorI2luY2x1ZGUgPGxpYmdlbi5oPgorCisjaW5j bHVkZSAiYmh5dmVydW4uaCIKKyNpbmNsdWRlICJwY2lfZW11bC5oIgorI2luY2x1ZGUgInZpcnRp by5oIgorI2luY2x1ZGUgIm1ldmVudC5oIgorCisjZGVmaW5lCVZUQ09OX1JJTkdTWgk2NAorI2Rl ZmluZQlWVENPTl9NQVhQT1JUUwkxNgorI2RlZmluZQlWVENPTl9NQVhRCShWVENPTl9NQVhQT1JU UyAqIDIgKyAyKQorCisjZGVmaW5lCVZUQ09OX0RFVklDRV9SRUFEWQkwCisjZGVmaW5lCVZUQ09O X0RFVklDRV9BREQJMQorI2RlZmluZQlWVENPTl9ERVZJQ0VfUkVNT1ZFCTIKKyNkZWZpbmUJVlRD T05fUE9SVF9SRUFEWQkzCisjZGVmaW5lCVZUQ09OX0NPTlNPTEVfUE9SVAk0CisjZGVmaW5lCVZU Q09OX0NPTlNPTEVfUkVTSVpFCTUKKyNkZWZpbmUJVlRDT05fUE9SVF9PUEVOCQk2CisjZGVmaW5l CVZUQ09OX1BPUlRfTkFNRQkJNworCisjZGVmaW5lCVZUQ09OX0ZfU0laRQkJMAorI2RlZmluZQlW VENPTl9GX01VTFRJUE9SVAkxCisjZGVmaW5lCVZUQ09OX0ZfRU1FUkdfV1JJVEUJMgorI2RlZmlu ZQlWVENPTl9TX0hPU1RDQVBTCVwKKyAgICAoVlRDT05fRl9TSVpFIHwgVlRDT05fRl9NVUxUSVBP UlQgfCBWVENPTl9GX0VNRVJHX1dSSVRFKQorCitzdGF0aWMgaW50IHBjaV92dGNvbl9kZWJ1ZzsK KyNkZWZpbmUgRFBSSU5URihwYXJhbXMpIGlmIChwY2lfdnRjb25fZGVidWcpIHByaW50ZiBwYXJh bXMKKyNkZWZpbmUgV1BSSU5URihwYXJhbXMpIHByaW50ZiBwYXJhbXMKKworc3RydWN0IHBjaV92 dGNvbl9zb2Z0YzsKK3N0cnVjdCBwY2lfdnRjb25fcG9ydDsKK3N0cnVjdCBwY2lfdnRjb25fY29u ZmlnOwordHlwZWRlZiB2b2lkIChwY2lfdnRjb25fY2JfdCkoc3RydWN0IHBjaV92dGNvbl9wb3J0 ICosIHZvaWQgKiwgc3RydWN0IGlvdmVjICosCisgICAgaW50KTsKKworc3RydWN0IHBjaV92dGNv bl9wb3J0IHsKKwlzdHJ1Y3QgcGNpX3Z0Y29uX3NvZnRjICogdnNwX3NjOworCWludCAgICAgICAg ICAgICAgICAgICAgICB2c3BfaWQ7CisJY29uc3QgY2hhciAqICAgICAgICAgICAgIHZzcF9uYW1l OworCWJvb2wgICAgICAgICAgICAgICAgICAgICB2c3BfZW5hYmxlZDsKKwlib29sICAgICAgICAg ICAgICAgICAgICAgdnNwX2NvbnNvbGU7CisJYm9vbCAgICAgICAgICAgICAgICAgICAgIHZzcF9y eF9yZWFkeTsKKwlpbnQgICAgICAgICAgICAgICAgICAgICAgdnNwX3J4cTsKKwlpbnQgICAgICAg ICAgICAgICAgICAgICAgdnNwX3R4cTsKKwl2b2lkICogICAgICAgICAgICAgICAgICAgdnNwX2Fy ZzsKKwlwY2lfdnRjb25fY2JfdCAqICAgICAgICAgdnNwX2NiOworfTsKKworc3RydWN0IHBjaV92 dGNvbl9zb2NrCit7CisJc3RydWN0IHBjaV92dGNvbl9wb3J0ICogIHZzc19wb3J0OworCWNvbnN0 IGNoYXIgKiAgICAgICAgICAgICB2c3NfcGF0aDsKKwlzdHJ1Y3QgbWV2ZW50ICogICAgICAgICAg dnNzX3NlcnZlcl9ldnA7CisJc3RydWN0IG1ldmVudCAqICAgICAgICAgIHZzc19jb25uX2V2cDsK KwlpbnQgICAgICAgICAgICAgICAgICAgICAgdnNzX3NlcnZlcl9mZDsKKwlpbnQgICAgICAgICAg ICAgICAgICAgICAgdnNzX2Nvbm5fZmQ7CisJYm9vbCAgICAgICAgICAgICAgICAgICAgIHZzc19v cGVuOworfTsKKworc3RydWN0IHBjaV92dGNvbl9zb2Z0YyB7CisJc3RydWN0IHZpcnRpb19zb2Z0 YyAgICAgIHZzY192czsKKwlzdHJ1Y3QgdnF1ZXVlX2luZm8gICAgICAgdnNjX3F1ZXVlc1tWVENP Tl9NQVhRXTsKKwlwdGhyZWFkX211dGV4X3QgICAgICAgICAgdnNjX210eDsKKwl1aW50NjRfdCAg ICAgICAgICAgICAgICAgdnNjX2NmZzsKKwl1aW50NjRfdCAgICAgICAgICAgICAgICAgdnNjX2Zl YXR1cmVzOworCWNoYXIgKiAgICAgICAgICAgICAgICAgICB2c2Nfcm9vdGRpcjsKKwlpbnQgICAg ICAgICAgICAgICAgICAgICAgdnNjX2txOworCWludCAgICAgICAgICAgICAgICAgICAgICB2c2Nf bnBvcnRzOworCXN0cnVjdCBwY2lfdnRjb25fcG9ydCAgICB2c2NfY29udHJvbF9wb3J0OworIAlz dHJ1Y3QgcGNpX3Z0Y29uX3BvcnQgICAgdnNjX3BvcnRzW1ZUQ09OX01BWFBPUlRTXTsKKwlzdHJ1 Y3QgcGNpX3Z0Y29uX2NvbmZpZyAqdnNjX2NvbmZpZzsKK307CisKK3N0cnVjdCBwY2lfdnRjb25f Y29uZmlnIHsKKwl1aW50MTZfdCBjb2xzOworCXVpbnQxNl90IHJvd3M7CisJdWludDMyX3QgbWF4 X25yX3BvcnRzOworCXVpbnQzMl90IGVtZXJnX3dyOworfSBfX2F0dHJpYnV0ZV9fKChwYWNrZWQp KTsKKworc3RydWN0IHBjaV92dGNvbl9jb250cm9sIHsKKwl1aW50MzJfdCBpZDsKKwl1aW50MTZf dCBldmVudDsKKwl1aW50MTZfdCB2YWx1ZTsKK30gX19hdHRyaWJ1dGVfXygocGFja2VkKSk7CisK K3N0cnVjdCBwY2lfdnRjb25fY29uc29sZV9yZXNpemUgeworCXVpbnQxNl90IGNvbHM7CisJdWlu dDE2X3Qgcm93czsKK30gX19hdHRyaWJ1dGVfXygocGFja2VkKSk7CisKK3N0YXRpYyB2b2lkIHBj aV92dGNvbl9yZXNldCh2b2lkICopOworc3RhdGljIHZvaWQgcGNpX3Z0Y29uX25vdGlmeV9yeCh2 b2lkICosIHN0cnVjdCB2cXVldWVfaW5mbyAqKTsKK3N0YXRpYyB2b2lkIHBjaV92dGNvbl9ub3Rp ZnlfdHgodm9pZCAqLCBzdHJ1Y3QgdnF1ZXVlX2luZm8gKik7CitzdGF0aWMgaW50IHBjaV92dGNv bl9jZmdyZWFkKHZvaWQgKiwgaW50LCBpbnQsIHVpbnQzMl90ICopOworc3RhdGljIGludCBwY2lf dnRjb25fY2Znd3JpdGUodm9pZCAqLCBpbnQsIGludCwgdWludDMyX3QpOworc3RhdGljIHZvaWQg cGNpX3Z0Y29uX25lZ19mZWF0dXJlcyh2b2lkICosIHVpbnQ2NF90KTsKK3N0YXRpYyB2b2lkIHBj aV92dGNvbl9zb2NrX2FjY2VwdChpbnQsIGVudW0gZXZfdHlwZSwgIHZvaWQgKik7CitzdGF0aWMg dm9pZCBwY2lfdnRjb25fc29ja19yeChpbnQsIGVudW0gZXZfdHlwZSwgdm9pZCAqKTsKK3N0YXRp YyB2b2lkIHBjaV92dGNvbl9zb2NrX3R4KHN0cnVjdCBwY2lfdnRjb25fcG9ydCAqLCB2b2lkICos IHN0cnVjdCBpb3ZlYyAqLAorICAgIGludCk7CitzdGF0aWMgdm9pZCBwY2lfdnRjb25fY29udHJv bF9zZW5kKHN0cnVjdCBwY2lfdnRjb25fc29mdGMgKiwKKyAgICBzdHJ1Y3QgcGNpX3Z0Y29uX2Nv bnRyb2wgKiwgY29uc3Qgdm9pZCAqLCBzaXplX3QpOworc3RhdGljIHZvaWQgcGNpX3Z0Y29uX2Fu bm91bmNlX3BvcnQoc3RydWN0IHBjaV92dGNvbl9wb3J0ICopOworc3RhdGljIHZvaWQgcGNpX3Z0 Y29uX29wZW5fcG9ydChzdHJ1Y3QgcGNpX3Z0Y29uX3BvcnQgKiwgYm9vbCk7CisKK3N0YXRpYyBz dHJ1Y3QgdmlydGlvX2NvbnN0cyB2dGNvbl92aV9jb25zdHMgPSB7CisJInZ0Y29uIiwJCS8qIG91 ciBuYW1lICovCisJVlRDT05fTUFYUSwJCS8qIHdlIHN1cHBvcnQgVlRDT05fTUFYUSB2aXJ0cXVl dWVzICovCisJc2l6ZW9mKHN0cnVjdCBwY2lfdnRjb25fY29uZmlnKSwgLyogY29uZmlnIHJlZyBz aXplICovCisJcGNpX3Z0Y29uX3Jlc2V0LAkvKiByZXNldCAqLworCU5VTEwsCQkJLyogZGV2aWNl LXdpZGUgcW5vdGlmeSAqLworCXBjaV92dGNvbl9jZmdyZWFkLAkvKiByZWFkIHZpcnRpbyBjb25m aWcgKi8KKwlwY2lfdnRjb25fY2Znd3JpdGUsCS8qIHdyaXRlIHZpcnRpbyBjb25maWcgKi8KKwlw Y2lfdnRjb25fbmVnX2ZlYXR1cmVzLAkvKiBhcHBseSBuZWdvdGlhdGVkIGZlYXR1cmVzICovCisJ VlRDT05fU19IT1NUQ0FQUywJLyogb3VyIGNhcGFiaWxpdGllcyAqLworfTsKKworCitzdGF0aWMg dm9pZAorcGNpX3Z0Y29uX3Jlc2V0KHZvaWQgKnZzYykKK3sKKwlzdHJ1Y3QgcGNpX3Z0Y29uX3Nv ZnRjICpzYzsKKworCXNjID0gdnNjOworCisJRFBSSU5URigoInZ0Y29uOiBkZXZpY2UgcmVzZXQg cmVxdWVzdGVkIVxuIikpOworCXZpX3Jlc2V0X2Rldigmc2MtPnZzY192cyk7Cit9CisKK3N0YXRp YyB2b2lkCitwY2lfdnRjb25fbmVnX2ZlYXR1cmVzKHZvaWQgKnZzYywgdWludDY0X3QgbmVnb3Rp YXRlZF9mZWF0dXJlcykKK3sKKwlzdHJ1Y3QgcGNpX3Z0Y29uX3NvZnRjICpzYyA9IHZzYzsKKwor CXNjLT52c2NfZmVhdHVyZXMgPSBuZWdvdGlhdGVkX2ZlYXR1cmVzOworfQorCitzdGF0aWMgaW50 CitwY2lfdnRjb25fY2ZncmVhZCh2b2lkICp2c2MsIGludCBvZmZzZXQsIGludCBzaXplLCB1aW50 MzJfdCAqcmV0dmFsKQoreworCXN0cnVjdCBwY2lfdnRjb25fc29mdGMgKnNjID0gdnNjOworCXZv aWQgKnB0cjsKKworCXB0ciA9ICh1aW50OF90ICopc2MtPnZzY19jb25maWcgKyBvZmZzZXQ7CisJ bWVtY3B5KHJldHZhbCwgcHRyLCBzaXplKTsKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50 CitwY2lfdnRjb25fY2Znd3JpdGUodm9pZCAqdnNjLCBpbnQgb2Zmc2V0LCBpbnQgc2l6ZSwgdWlu dDMyX3QgdmFsKQoreworCisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIGlubGluZSBzdHJ1Y3Qg cGNpX3Z0Y29uX3BvcnQgKgorcGNpX3Z0Y29uX3ZxX3RvX3BvcnQoc3RydWN0IHBjaV92dGNvbl9z b2Z0YyAqc2MsIHN0cnVjdCB2cXVldWVfaW5mbyAqdnEpCit7CisJdWludDE2X3QgbnVtID0gdnEt PnZxX251bTsKKworCWlmIChudW0gPT0gMCB8fCBudW0gPT0gMSkKKwkJcmV0dXJuICgmc2MtPnZz Y19wb3J0c1swXSk7CisKKwlpZiAobnVtID09IDIgfHwgbnVtID09IDMpCisJCXJldHVybiAoJnNj LT52c2NfY29udHJvbF9wb3J0KTsKKworCXJldHVybiAoJnNjLT52c2NfcG9ydHNbKG51bSAvIDIp IC0gMV0pOworfQorCitzdGF0aWMgaW5saW5lIHN0cnVjdCB2cXVldWVfaW5mbyAqCitwY2lfdnRj b25fcG9ydF90b192cShzdHJ1Y3QgcGNpX3Z0Y29uX3BvcnQgKnBvcnQsIGJvb2wgdHhfcXVldWUp Cit7CisJaW50IHFudW07CisKKwlxbnVtID0gdHhfcXVldWUgPyBwb3J0LT52c3BfdHhxIDogcG9y dC0+dnNwX3J4cTsKKwlyZXR1cm4gKCZwb3J0LT52c3Bfc2MtPnZzY19xdWV1ZXNbcW51bV0pOwor fQorCitzdGF0aWMgc3RydWN0IHBjaV92dGNvbl9wb3J0ICoKK3BjaV92dGNvbl9wb3J0X2FkZChz dHJ1Y3QgcGNpX3Z0Y29uX3NvZnRjICpzYywgY29uc3QgY2hhciAqbmFtZSwKKyAgICBwY2lfdnRj b25fY2JfdCAqY2IsIHZvaWQgKmFyZykKK3sKKwlzdHJ1Y3QgcGNpX3Z0Y29uX3BvcnQgKnBvcnQ7 CisKKwlpZiAoc2MtPnZzY19ucG9ydHMgPT0gVlRDT05fTUFYUE9SVFMpIHsKKwkJZXJybm8gPSBF QlVTWTsKKwkJcmV0dXJuIChOVUxMKTsKKwl9CisKKwlwb3J0ID0gJnNjLT52c2NfcG9ydHNbc2Mt PnZzY19ucG9ydHMrK107CisJcG9ydC0+dnNwX2lkID0gc2MtPnZzY19ucG9ydHMgLSAxOworCXBv cnQtPnZzcF9zYyA9IHNjOworCXBvcnQtPnZzcF9uYW1lID0gbmFtZTsKKwlwb3J0LT52c3BfY2Ig PSBjYjsKKwlwb3J0LT52c3BfYXJnID0gYXJnOworCisJaWYgKHBvcnQtPnZzcF9pZCA9PSAwKSB7 CisJCS8qIHBvcnQwICovCisJCXBvcnQtPnZzcF90eHEgPSAwOworCQlwb3J0LT52c3BfcnhxID0g MTsKKwl9IGVsc2UgeworCQlwb3J0LT52c3BfdHhxID0gc2MtPnZzY19ucG9ydHMgKiAyOworCQlw b3J0LT52c3BfcnhxID0gcG9ydC0+dnNwX3R4cSArIDE7CisJfQorCisJcG9ydC0+dnNwX2VuYWJs ZWQgPSB0cnVlOworCXJldHVybiAocG9ydCk7Cit9CisKK3N0YXRpYyBpbnQKK3BjaV92dGNvbl9z b2NrX2FkZChzdHJ1Y3QgcGNpX3Z0Y29uX3NvZnRjICpzYywgY29uc3QgY2hhciAqbmFtZSwKKyAg ICBjb25zdCBjaGFyICpwYXRoKQoreworCXN0cnVjdCBwY2lfdnRjb25fc29jayAqc29jazsKKwlz dHJ1Y3Qgc29ja2FkZHJfdW4gc3VuOworCWludCBzID0gLTEsIGZkID0gLTEsIGVycm9yID0gMDsK KworCXNvY2sgPSBjYWxsb2MoMSwgc2l6ZW9mKHN0cnVjdCBwY2lfdnRjb25fc29jaykpOworCWlm IChzb2NrID09IE5VTEwpIHsKKwkJZXJyb3IgPSAtMTsKKwkJZ290byBvdXQ7CisJfQorCisJcyA9 IHNvY2tldChBRl9VTklYLCBTT0NLX1NUUkVBTSwgMCk7CisJaWYgKHMgPCAwKSB7CisJCWVycm9y ID0gLTE7CisJCWdvdG8gb3V0OworCX0KKworCWZkID0gb3BlbihkaXJuYW1lKHBhdGgpLCBPX1JE T05MWSB8IE9fRElSRUNUT1JZKTsKKwlpZiAoZmQgPCAwKSB7CisJCWVycm9yID0gLTE7CisJCWdv dG8gb3V0OworCX0KKworCXN1bi5zdW5fZmFtaWx5ID0gQUZfVU5JWDsKKwlzdW4uc3VuX2xlbiA9 IHNpemVvZihzdHJ1Y3Qgc29ja2FkZHJfdW4pOworCXN0cm5jcHkoc3VuLnN1bl9wYXRoLCBiYXNl bmFtZShwYXRoKSwgc2l6ZW9mKHN1bi5zdW5fcGF0aCkpOworCisJaWYgKGJpbmRhdChmZCwgcywg KHN0cnVjdCBzb2NrYWRkciAqKSZzdW4sIHN1bi5zdW5fbGVuKSA8IDApIHsKKwkJZXJyb3IgPSAt MTsKKwkJZ290byBvdXQ7CisJfQorCisJaWYgKGZjbnRsKHMsIEZfU0VURkwsIE9fTk9OQkxPQ0sp IDwgMCkgeworCQllcnJvciA9IC0xOworCQlnb3RvIG91dDsKKwl9CisKKwlpZiAobGlzdGVuKHMs IDEpIDwgMCkgeworCQllcnJvciA9IC0xOworCQlnb3RvIG91dDsKKwl9CisKKworCXNvY2stPnZz c19wb3J0ID0gcGNpX3Z0Y29uX3BvcnRfYWRkKHNjLCBuYW1lLCBwY2lfdnRjb25fc29ja190eCwg c29jayk7CisJaWYgKHNvY2stPnZzc19wb3J0ID09IE5VTEwpIHsKKwkJZXJyb3IgPSAtMTsKKwkJ Z290byBvdXQ7CisJfQorCisJc29jay0+dnNzX29wZW4gPSBmYWxzZTsKKwlzb2NrLT52c3NfY29u bl9mZCA9IC0xOworCXNvY2stPnZzc19zZXJ2ZXJfZmQgPSBzOworCXNvY2stPnZzc19zZXJ2ZXJf ZXZwID0gbWV2ZW50X2FkZChzLCBFVkZfUkVBRCwgcGNpX3Z0Y29uX3NvY2tfYWNjZXB0LAorCSAg ICBzb2NrKTsKKworCWlmIChzb2NrLT52c3Nfc2VydmVyX2V2cCA9PSBOVUxMKSB7CisJCWVycm9y ID0gLTE7CisJCWdvdG8gb3V0OworCX0KKworb3V0OgorCWlmIChmZCAhPSAtMSkKKwkJY2xvc2Uo ZmQpOworCisJaWYgKGVycm9yICE9IDAgJiYgcyAhPSAtMSkKKwkJY2xvc2Uocyk7CisKKwlyZXR1 cm4gKGVycm9yKTsKK30KKworc3RhdGljIHZvaWQKK3BjaV92dGNvbl9zb2NrX2FjY2VwdChpbnQg ZmQgX191bnVzZWQsIGVudW0gZXZfdHlwZSB0IF9fdW51c2VkLCB2b2lkICphcmcpCit7CisJc3Ry dWN0IHBjaV92dGNvbl9zb2NrICpzb2NrID0gKHN0cnVjdCBwY2lfdnRjb25fc29jayAqKWFyZzsK KwlpbnQgczsKKworCXMgPSBhY2NlcHQoc29jay0+dnNzX3NlcnZlcl9mZCwgTlVMTCwgTlVMTCk7 CisJaWYgKHMgPCAwKQorCQlyZXR1cm47CisKKwlpZiAoc29jay0+dnNzX29wZW4pIHsKKwkJY2xv c2Uocyk7CisJCXJldHVybjsKKwl9CisKKwlzb2NrLT52c3Nfb3BlbiA9IHRydWU7CisJc29jay0+ dnNzX2Nvbm5fZmQgPSBzOworCXNvY2stPnZzc19jb25uX2V2cCA9IG1ldmVudF9hZGQocywgRVZG X1JFQUQsIHBjaV92dGNvbl9zb2NrX3J4LCBzb2NrKTsKKwlwY2lfdnRjb25fb3Blbl9wb3J0KHNv Y2stPnZzc19wb3J0LCB0cnVlKTsKK30KKworc3RhdGljIHZvaWQKK3BjaV92dGNvbl9zb2NrX3J4 KGludCBmZCBfX3VudXNlZCwgZW51bSBldl90eXBlIHQgX191bnVzZWQsIHZvaWQgKmFyZykKK3sK KwlzdHJ1Y3QgcGNpX3Z0Y29uX3BvcnQgKnBvcnQ7CisJc3RydWN0IHBjaV92dGNvbl9zb2NrICpz b2NrID0gKHN0cnVjdCBwY2lfdnRjb25fc29jayAqKWFyZzsKKwlzdHJ1Y3QgdnF1ZXVlX2luZm8g KnZxOworCXN0cnVjdCBpb3ZlYyBpb3Y7CisJc3RhdGljIGNoYXIgZHVtbXlidWZbMjA0OF07CisJ aW50IGxlbiwgbjsKKwl1aW50MTZfdCBpZHg7CisKKwlwb3J0ID0gc29jay0+dnNzX3BvcnQ7CisJ dnEgPSBwY2lfdnRjb25fcG9ydF90b192cShwb3J0LCB0cnVlKTsKKworCWlmICghc29jay0+dnNz X29wZW4gfHwgIXBvcnQtPnZzcF9yeF9yZWFkeSkgeworCQlsZW4gPSByZWFkKHNvY2stPnZzc19j b25uX2ZkLCBkdW1teWJ1Ziwgc2l6ZW9mKGR1bW15YnVmKSk7CisJCWlmIChsZW4gPT0gMCkKKwkJ CWdvdG8gY2xvc2U7CisKKwkJcmV0dXJuOworCX0KKworCWlmICghdnFfaGFzX2Rlc2NzKHZxKSkg eworCQlsZW4gPSByZWFkKHNvY2stPnZzc19jb25uX2ZkLCBkdW1teWJ1Ziwgc2l6ZW9mKGR1bW15 YnVmKSk7CisJCXZxX2VuZGNoYWlucyh2cSwgMSk7CisJCWlmIChsZW4gPT0gMCkKKwkJCWdvdG8g Y2xvc2U7CisKKwkJcmV0dXJuOworCX0KKworCWRvIHsKKwkJbiA9IHZxX2dldGNoYWluKHZxLCAm aWR4LCAmaW92LCAxLCBOVUxMKTsKKwkJbGVuID0gcmVhZHYoc29jay0+dnNzX2Nvbm5fZmQsICZp b3YsIG4pOworCisJCWlmIChsZW4gPT0gMCB8fCAobGVuIDwgMCAmJiBlcnJubyA9PSBFV09VTERC TE9DSykpIHsKKwkJCXZxX3JldGNoYWluKHZxKTsKKwkJCXZxX2VuZGNoYWlucyh2cSwgMCk7CisJ CQlpZiAobGVuID09IDApCisJCQkJZ290byBjbG9zZTsKKworCQkJcmV0dXJuOworCQl9CisKKwkJ dnFfcmVsY2hhaW4odnEsIGlkeCwgbGVuKTsKKwl9IHdoaWxlICh2cV9oYXNfZGVzY3ModnEpKTsK KworCXZxX2VuZGNoYWlucyh2cSwgMSk7CisKK2Nsb3NlOgorCW1ldmVudF9kZWxldGVfY2xvc2Uo c29jay0+dnNzX2Nvbm5fZXZwKTsKKwlzb2NrLT52c3NfY29ubl9mZCA9IC0xOworCXNvY2stPnZz c19vcGVuID0gZmFsc2U7Cit9CisKK3N0YXRpYyB2b2lkCitwY2lfdnRjb25fc29ja190eChzdHJ1 Y3QgcGNpX3Z0Y29uX3BvcnQgKnBvcnQsIHZvaWQgKmFyZywgc3RydWN0IGlvdmVjICppb3YsCisg ICAgaW50IG5pb3YpCit7CisJc3RydWN0IHBjaV92dGNvbl9zb2NrICpzb2NrOworCWludCByZXQ7 CisKKwlzb2NrID0gKHN0cnVjdCBwY2lfdnRjb25fc29jayAqKWFyZzsKKworCWlmIChzb2NrLT52 c3NfY29ubl9mZCA9PSAtMSkKKwkJcmV0dXJuOworCisJcmV0ID0gd3JpdGV2KHNvY2stPnZzc19j b25uX2ZkLCBpb3YsIG5pb3YpOworCisJaWYgKHJldCA8IDAgJiYgZXJybm8gIT0gRVdPVUxEQkxP Q0spIHsKKwkJbWV2ZW50X2RlbGV0ZV9jbG9zZShzb2NrLT52c3NfY29ubl9ldnApOworCQlzb2Nr LT52c3NfY29ubl9mZCA9IC0xOworCQlzb2NrLT52c3Nfb3BlbiA9IGZhbHNlOworCX0KK30KKwor c3RhdGljIHZvaWQKK3BjaV92dGNvbl9jb250cm9sX3R4KHN0cnVjdCBwY2lfdnRjb25fcG9ydCAq cG9ydCwgdm9pZCAqYXJnLCBzdHJ1Y3QgaW92ZWMgKmlvdiwKKyAgICBpbnQgbmlvdikKK3sKKwlz dHJ1Y3QgcGNpX3Z0Y29uX3NvZnRjICpzYzsKKwlzdHJ1Y3QgcGNpX3Z0Y29uX3BvcnQgKnRtcDsK KwlzdHJ1Y3QgcGNpX3Z0Y29uX2NvbnRyb2wgcmVzcCwgKmN0cmw7CisJaW50IGk7CisKKwlhc3Nl cnQobmlvdiA9PSAxKTsKKworCXNjID0gcG9ydC0+dnNwX3NjOworCWN0cmwgPSAoc3RydWN0IHBj aV92dGNvbl9jb250cm9sICopaW92LT5pb3ZfYmFzZTsKKworCXN3aXRjaCAoY3RybC0+ZXZlbnQp IHsKKwljYXNlIFZUQ09OX0RFVklDRV9SRUFEWToKKwkJLyogc2V0IHBvcnQgcmVhZHkgZXZlbnRz IGZvciByZWdpc3RlcmVkIHBvcnRzICovCisJCWZvciAoaSA9IDA7IGkgPCBWVENPTl9NQVhQT1JU UzsgaSsrKSB7CisJCQl0bXAgPSAmc2MtPnZzY19wb3J0c1tpXTsKKwkJCWlmICh0bXAtPnZzcF9l bmFibGVkKQorCQkJCXBjaV92dGNvbl9hbm5vdW5jZV9wb3J0KHRtcCk7CisJCX0KKwkJYnJlYWs7 CisKKwljYXNlIFZUQ09OX1BPUlRfUkVBRFk6CisJCWlmIChjdHJsLT5pZCA+PSBzYy0+dnNjX25w b3J0cykgeworCQkJV1BSSU5URigoIlZUQ09OX1BPUlRfUkVBRFkgZXZlbnQgZm9yIHVua25vd24g cG9ydCAlZFxuIiwKKwkJCSAgICBjdHJsLT5pZCkpOworCQkJcmV0dXJuOworCQl9CisKKwkJdG1w ID0gJnNjLT52c2NfcG9ydHNbY3RybC0+aWRdOworCQlpZiAodG1wLT52c3BfY29uc29sZSkgewor CQkJcmVzcC5ldmVudCA9IFZUQ09OX0NPTlNPTEVfUE9SVDsKKwkJCXJlc3AuaWQgPSBjdHJsLT5p ZDsKKwkJCXJlc3AudmFsdWUgPSAxOworCQkJcGNpX3Z0Y29uX2NvbnRyb2xfc2VuZChzYywgJnJl c3AsIE5VTEwsIDApOworCQl9CisJCWJyZWFrOworCX0KK30KKworc3RhdGljIHZvaWQKK3BjaV92 dGNvbl9hbm5vdW5jZV9wb3J0KHN0cnVjdCBwY2lfdnRjb25fcG9ydCAqcG9ydCkKK3sKKwlzdHJ1 Y3QgcGNpX3Z0Y29uX2NvbnRyb2wgZXZlbnQ7CisKKwlldmVudC5pZCA9IHBvcnQtPnZzcF9pZDsK KwlldmVudC5ldmVudCA9IFZUQ09OX0RFVklDRV9BREQ7CisJZXZlbnQudmFsdWUgPSAxOworCXBj aV92dGNvbl9jb250cm9sX3NlbmQocG9ydC0+dnNwX3NjLCAmZXZlbnQsIE5VTEwsIDApOworCisJ ZXZlbnQuZXZlbnQgPSBWVENPTl9QT1JUX05BTUU7CisJcGNpX3Z0Y29uX2NvbnRyb2xfc2VuZChw b3J0LT52c3Bfc2MsICZldmVudCwgcG9ydC0+dnNwX25hbWUsCisJICAgIHN0cmxlbihwb3J0LT52 c3BfbmFtZSkpOworfQorCitzdGF0aWMgdm9pZAorcGNpX3Z0Y29uX29wZW5fcG9ydChzdHJ1Y3Qg cGNpX3Z0Y29uX3BvcnQgKnBvcnQsIGJvb2wgb3BlbikKK3sKKwlzdHJ1Y3QgcGNpX3Z0Y29uX2Nv bnRyb2wgZXZlbnQ7CisKKwlldmVudC5pZCA9IHBvcnQtPnZzcF9pZDsKKwlldmVudC5ldmVudCA9 IFZUQ09OX1BPUlRfT1BFTjsKKwlldmVudC52YWx1ZSA9IChpbnQpb3BlbjsKKwlwY2lfdnRjb25f Y29udHJvbF9zZW5kKHBvcnQtPnZzcF9zYywgJmV2ZW50LCBOVUxMLCAwKTsKK30KKworc3RhdGlj IHZvaWQKK3BjaV92dGNvbl9jb250cm9sX3NlbmQoc3RydWN0IHBjaV92dGNvbl9zb2Z0YyAqc2Ms CisgICAgc3RydWN0IHBjaV92dGNvbl9jb250cm9sICpjdHJsLCBjb25zdCB2b2lkICpwYXlsb2Fk LCBzaXplX3QgbGVuKQoreworCXN0cnVjdCB2cXVldWVfaW5mbyAqdnE7CisJc3RydWN0IGlvdmVj IGlvdjsKKwl1aW50MTZfdCBpZHg7CisJaW50IG47CisKKwl2cSA9IHBjaV92dGNvbl9wb3J0X3Rv X3ZxKCZzYy0+dnNjX2NvbnRyb2xfcG9ydCwgdHJ1ZSk7CisKKwlpZiAoIXZxX2hhc19kZXNjcyh2 cSkpCisJCXJldHVybjsKKworCW4gPSB2cV9nZXRjaGFpbih2cSwgJmlkeCwgJmlvdiwgMSwgTlVM TCk7CisKKwlhc3NlcnQobiA9PSAxKTsKKworCW1lbWNweShpb3YuaW92X2Jhc2UsIGN0cmwsIHNp emVvZihzdHJ1Y3QgcGNpX3Z0Y29uX2NvbnRyb2wpKTsKKwlpZiAocGF5bG9hZCAhPSBOVUxMICYm IGxlbiA+IDApCisJCW1lbWNweShpb3YuaW92X2Jhc2UgKyBzaXplb2Yoc3RydWN0IHBjaV92dGNv bl9jb250cm9sKSwKKwkJICAgICBwYXlsb2FkLCBsZW4pOworCisJdnFfcmVsY2hhaW4odnEsIGlk eCwgc2l6ZW9mKHN0cnVjdCBwY2lfdnRjb25fY29udHJvbCkgKyBsZW4pOworCXZxX2VuZGNoYWlu cyh2cSwgMSk7Cit9CisgICAgCisKK3N0YXRpYyB2b2lkCitwY2lfdnRjb25fbm90aWZ5X3R4KHZv aWQgKnZzYywgc3RydWN0IHZxdWV1ZV9pbmZvICp2cSkKK3sKKwlzdHJ1Y3QgcGNpX3Z0Y29uX3Nv ZnRjICpzYzsKKwlzdHJ1Y3QgcGNpX3Z0Y29uX3BvcnQgKnBvcnQ7CisJc3RydWN0IGlvdmVjIGlv dlsxXTsKKwl1aW50MTZfdCBpZHgsIG47CisJdWludDE2X3QgZmxhZ3NbOF07CisKKwlzYyA9IHZz YzsKKwlwb3J0ID0gcGNpX3Z0Y29uX3ZxX3RvX3BvcnQoc2MsIHZxKTsKKworCXdoaWxlICh2cV9o YXNfZGVzY3ModnEpKSB7CisJCW4gPSB2cV9nZXRjaGFpbih2cSwgJmlkeCwgaW92LCAxLCBmbGFn cyk7CisJCWlmIChwb3J0ICE9IE5VTEwpCisJCQlwb3J0LT52c3BfY2IocG9ydCwgcG9ydC0+dnNw X2FyZywgaW92LCAxKTsKKworCQkvKgorCQkgKiBSZWxlYXNlIHRoaXMgY2hhaW4gYW5kIGhhbmRs ZSBtb3JlCisJCSAqLworCQl2cV9yZWxjaGFpbih2cSwgaWR4LCAwKTsKKwl9CisJdnFfZW5kY2hh aW5zKHZxLCAxKTsJLyogR2VuZXJhdGUgaW50ZXJydXB0IGlmIGFwcHJvcHJpYXRlLiAqLworfQor CitzdGF0aWMgdm9pZAorcGNpX3Z0Y29uX25vdGlmeV9yeCh2b2lkICp2c2MsIHN0cnVjdCB2cXVl dWVfaW5mbyAqdnEpCit7CisJc3RydWN0IHBjaV92dGNvbl9zb2Z0YyAqc2M7CisJc3RydWN0IHBj aV92dGNvbl9wb3J0ICpwb3J0OworCisJc2MgPSB2c2M7CisJcG9ydCA9IHBjaV92dGNvbl92cV90 b19wb3J0KHNjLCB2cSk7CisKKwlpZiAoIXBvcnQtPnZzcF9yeF9yZWFkeSkgeworCQlwb3J0LT52 c3BfcnhfcmVhZHkgPSAxOworCQl2cS0+dnFfdXNlZC0+dnVfZmxhZ3MgfD0gVlJJTkdfVVNFRF9G X05PX05PVElGWTsKKwl9Cit9CisKK3N0YXRpYyBpbnQKK3BjaV92dGNvbl9pbml0KHN0cnVjdCB2 bWN0eCAqY3R4LCBzdHJ1Y3QgcGNpX2Rldmluc3QgKnBpLCBjaGFyICpvcHRzKQoreworCXN0cnVj dCBwY2lfdnRjb25fc29mdGMgKnNjOworCWNoYXIgKnBvcnRuYW1lID0gTlVMTDsKKwljaGFyICpw b3J0cGF0aCA9IE5VTEw7CisJY2hhciAqb3B0OworCWludCBpOwkKKworCXNjID0gY2FsbG9jKDEs IHNpemVvZihzdHJ1Y3QgcGNpX3Z0Y29uX3NvZnRjKSk7CisJc2MtPnZzY19jb25maWcgPSBjYWxs b2MoMSwgc2l6ZW9mKHN0cnVjdCBwY2lfdnRjb25fY29uZmlnKSk7CisJc2MtPnZzY19jb25maWct Pm1heF9ucl9wb3J0cyA9IFZUQ09OX01BWFBPUlRTOworCXNjLT52c2NfY29uZmlnLT5jb2xzID0g ODA7CisJc2MtPnZzY19jb25maWctPnJvd3MgPSAyNTsgCisKKwl2aV9zb2Z0Y19saW5rdXAoJnNj LT52c2NfdnMsICZ2dGNvbl92aV9jb25zdHMsIHNjLCBwaSwgc2MtPnZzY19xdWV1ZXMpOworCXNj LT52c2NfdnMudnNfbXR4ID0gJnNjLT52c2NfbXR4OworCisJZm9yIChpID0gMDsgaSA8IFZUQ09O X01BWFE7IGkrKykgeworCQlzYy0+dnNjX3F1ZXVlc1tpXS52cV9xc2l6ZSA9IFZUQ09OX1JJTkdT WjsKKwkJc2MtPnZzY19xdWV1ZXNbaV0udnFfbm90aWZ5ID0gaSAlIDIgPT0gMAorCQkgICAgPyBw Y2lfdnRjb25fbm90aWZ5X3J4CisJCSAgICA6IHBjaV92dGNvbl9ub3RpZnlfdHg7CisJfQorCisJ LyogaW5pdGlhbGl6ZSBjb25maWcgc3BhY2UgKi8KKwlwY2lfc2V0X2NmZ2RhdGExNihwaSwgUENJ Ul9ERVZJQ0UsIFZJUlRJT19ERVZfQ09OU09MRSk7CisJcGNpX3NldF9jZmdkYXRhMTYocGksIFBD SVJfVkVORE9SLCBWSVJUSU9fVkVORE9SKTsKKwlwY2lfc2V0X2NmZ2RhdGE4KHBpLCBQQ0lSX0NM QVNTLCBQQ0lDX1NJTVBMRUNPTU0pOworCXBjaV9zZXRfY2ZnZGF0YTE2KHBpLCBQQ0lSX1NVQkRF Vl8wLCBWSVJUSU9fVFlQRV9DT05TT0xFKTsKKwlwY2lfc2V0X2NmZ2RhdGExNihwaSwgUENJUl9T VUJWRU5EXzAsIFZJUlRJT19WRU5ET1IpOworCisJaWYgKHZpX2ludHJfaW5pdCgmc2MtPnZzY192 cywgMSwgZmJzZHJ1bl92aXJ0aW9fbXNpeCgpKSkKKwkJcmV0dXJuICgxKTsKKwl2aV9zZXRfaW9f YmFyKCZzYy0+dnNjX3ZzLCAwKTsKKworCS8qIGNyZWF0ZSBjb250cm9sIHBvcnQgKi8KKwlzYy0+ dnNjX2NvbnRyb2xfcG9ydC52c3Bfc2MgPSBzYzsKKwlzYy0+dnNjX2NvbnRyb2xfcG9ydC52c3Bf dHhxID0gMjsKKwlzYy0+dnNjX2NvbnRyb2xfcG9ydC52c3BfcnhxID0gMzsKKwlzYy0+dnNjX2Nv bnRyb2xfcG9ydC52c3BfY2IgPSBwY2lfdnRjb25fY29udHJvbF90eDsKKwlzYy0+dnNjX2NvbnRy b2xfcG9ydC52c3BfZW5hYmxlZCA9IHRydWU7CisKKwl3aGlsZSAoKG9wdCA9IHN0cnNlcCgmb3B0 cywgIiwiKSkgIT0gTlVMTCkgeworCQlwb3J0bmFtZSA9IHN0cnNlcCgmb3B0LCAiPSIpOworCQlw b3J0cGF0aCA9IHN0cmR1cChvcHQpOworCisJCS8qIGNyZWF0ZSBwb3J0ICovCisJCWlmIChwY2lf dnRjb25fc29ja19hZGQoc2MsIHBvcnRuYW1lLCBwb3J0cGF0aCkgPCAwKSB7CisJCQlmcHJpbnRm KHN0ZGVyciwgImNhbm5vdCBjcmVhdGUgcG9ydCAlczogJXNcbiIsCisJCQkgICAgcG9ydG5hbWUs IHN0cmVycm9yKGVycm5vKSk7CisJCQlyZXR1cm4gKDEpOworCQl9CisJfQorCisJcmV0dXJuICgw KTsKK30KKworc3RydWN0IHBjaV9kZXZlbXUgcGNpX2RlX3Zjb24gPSB7CisJLnBlX2VtdSA9CSJ2 aXJ0aW8tY29uc29sZSIsCisJLnBlX2luaXQgPQlwY2lfdnRjb25faW5pdCwKKwkucGVfYmFyd3Jp dGUgPQl2aV9wY2lfd3JpdGUsCisJLnBlX2JhcnJlYWQgPQl2aV9wY2lfcmVhZAorfTsKK1BDSV9F TVVMX1NFVChwY2lfZGVfdmNvbik7CmRpZmYgLS1naXQgYS91c3Iuc2Jpbi9iaHl2ZS9NYWtlZmls ZSBiL3Vzci5zYmluL2JoeXZlL01ha2VmaWxlCi0tLSBhL3Vzci5zYmluL2JoeXZlL01ha2VmaWxl CisrKyBiL3Vzci5zYmluL2JoeXZlL01ha2VmaWxlCkBAIC0zNiw2ICszNiw3IEBACiAJcGNpX2xw Yy5jCQlcCiAJcGNpX3Bhc3N0aHJ1LmMJCVwKIAlwY2lfdmlydGlvX2Jsb2NrLmMJXAorCXBjaV92 aXJ0aW9fY29uc29sZS5jCVwKIAlwY2lfdmlydGlvX25ldC5jCVwKIAlwY2lfdmlydGlvX3JuZC5j CVwKIAlwY2lfdWFydC5jCQlcCgo= --b1_a323306a2e70d59516842eb696491cc6-- From owner-freebsd-virtualization@freebsd.org Mon Jul 11 17:27:35 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 67A2AB92F1B for ; Mon, 11 Jul 2016 17:27:35 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (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 583011789 for ; Mon, 11 Jul 2016 17:27:35 +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 3E32C3AF90; Mon, 11 Jul 2016 17:27:29 +0000 (UTC) Message-ID: <5783D6FF.7010107@redbarn.org> Date: Mon, 11 Jul 2016 10:27:27 -0700 From: Paul Vixie User-Agent: Postbox 4.0.8 (Windows/20151105) MIME-Version: 1.0 To: D7185+333+7754cf487cff2162@reviews.freebsd.org CC: freebsd-virtualization@freebsd.org Subject: Re: [Differential] D7185: Add virtio-console support to bhyve References: 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: Mon, 11 Jul 2016 17:27:35 -0000 fwiw, bhyve's existing console support is working fine for me. i use rtty (from ports). my configuration looks like this: [mm1.redbarn:amd64] ls -l /usr/local/rtty/dev total 3 lrwxr-xr-x 1 root wheel 11 May 18 2014 family@ -> /dev/nmdm2A lrwxr-xr-x 1 root wheel 11 May 17 2014 guests@ -> /dev/nmdm0A lrwxr-xr-x 1 root wheel 11 Nov 16 2014 pbx@ -> /dev/nmdm5A lrwxr-xr-x 1 root wheel 11 Jun 1 2014 sleipnir@ -> /dev/nmdm3A lrwxr-xr-x 1 root wheel 11 May 18 2014 util@ -> /dev/nmdm1A lrwxr-xr-x 1 root wheel 11 May 1 2015 yeti-dns@ -> /dev/nmdm7A the bhyve processes are using the corresponding "B" devices. rtty keeps logs: [mm1.redbarn:amd64] ls -l /usr/local/rtty/log/ total 164401 -rw-r----- 1 root wheel 2132344 Jul 10 07:18 family -rw-r----- 1 root wheel 1176529 Jul 10 03:58 guests -rw-r----- 1 root wheel 1964961 Jul 11 06:23 pbx -rw-r----- 1 root wheel 133664527 Jul 11 17:25 sleipnir -rw-r----- 1 root wheel 17943116 Jul 11 17:06 util -rw-r----- 1 root wheel 11042436 Jul 11 17:11 yeti-dns so i can find out why something crashed even if i wasn't watching at the time. so, i'm having trouble understanding the need for virtio-console to be able to open a host-side unix-domain socket in the file system? vixie (author of rtty) From owner-freebsd-virtualization@freebsd.org Mon Jul 11 18:01:17 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 0F787B92B2C for ; Mon, 11 Jul 2016 18:01:17 +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 CA39711C0 for ; Mon, 11 Jul 2016 18:01:16 +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 <0OA5007GSWPW4K20@mta.uoks.uj.edu.pl> for freebsd-virtualization@freebsd.org; Mon, 11 Jul 2016 20:01:09 +0200 (CEST) Subject: Re: [Differential] D7185: Add virtio-console support to bhyve From: Jakub Klama In-reply-to: <5783D6FF.7010107@redbarn.org> Date: Mon, 11 Jul 2016 20:01:08 +0200 Cc: D7185+333+7754cf487cff2162@reviews.freebsd.org, freebsd-virtualization@freebsd.org Content-transfer-encoding: quoted-printable Message-id: References: <5783D6FF.7010107@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 18:01:17 -0000 > Wiadomo=C5=9B=C4=87 napisana przez Paul Vixie w = dniu 11.07.2016, o godz. 19:27: >=20 > fwiw, bhyve's existing console support is working fine for me. i use = rtty (from ports). my configuration looks like this: >=20 > [mm1.redbarn:amd64] ls -l /usr/local/rtty/dev > total 3 > lrwxr-xr-x 1 root wheel 11 May 18 2014 family@ -> /dev/nmdm2A > lrwxr-xr-x 1 root wheel 11 May 17 2014 guests@ -> /dev/nmdm0A > lrwxr-xr-x 1 root wheel 11 Nov 16 2014 pbx@ -> /dev/nmdm5A > lrwxr-xr-x 1 root wheel 11 Jun 1 2014 sleipnir@ -> /dev/nmdm3A > lrwxr-xr-x 1 root wheel 11 May 18 2014 util@ -> /dev/nmdm1A > lrwxr-xr-x 1 root wheel 11 May 1 2015 yeti-dns@ -> /dev/nmdm7A >=20 > the bhyve processes are using the corresponding "B" devices. rtty = keeps logs: >=20 > [mm1.redbarn:amd64] ls -l /usr/local/rtty/log/ > total 164401 > -rw-r----- 1 root wheel 2132344 Jul 10 07:18 family > -rw-r----- 1 root wheel 1176529 Jul 10 03:58 guests > -rw-r----- 1 root wheel 1964961 Jul 11 06:23 pbx > -rw-r----- 1 root wheel 133664527 Jul 11 17:25 sleipnir > -rw-r----- 1 root wheel 17943116 Jul 11 17:06 util > -rw-r----- 1 root wheel 11042436 Jul 11 17:11 yeti-dns >=20 > so i can find out why something crashed even if i wasn't watching at = the time. >=20 > so, i'm having trouble understanding the need for virtio-console to be = able to open a host-side unix-domain socket in the file system? >=20 The purpose of virtio-console is to create arbitrary bidirectional, = host-to-guest communication channels that bypass guest's network stack (don't require working = networking in the guest). But even for using it as the system console, it's a bit better than = emulated serial port, because the protocol supports passing console resize events from host to guest. Jakub= From owner-freebsd-virtualization@freebsd.org Mon Jul 11 18:18:42 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 1DD77B92253 for ; Mon, 11 Jul 2016 18:18:42 +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 0F4081192 for ; Mon, 11 Jul 2016 18:18:41 +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 E4F013AF8E; Mon, 11 Jul 2016 18:18:40 +0000 (UTC) Message-ID: <5783E2FE.1040309@redbarn.org> Date: Mon, 11 Jul 2016 11:18:38 -0700 From: Paul Vixie User-Agent: Postbox 4.0.8 (Windows/20151105) MIME-Version: 1.0 To: Jakub Klama CC: D7185+333+7754cf487cff2162@reviews.freebsd.org, freebsd-virtualization@freebsd.org Subject: Re: [Differential] D7185: Add virtio-console support to bhyve References: <5783D6FF.7010107@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: Mon, 11 Jul 2016 18:18:42 -0000 Jakub Klama wrote: > The purpose of virtio-console is to create arbitrary bidirectional, host-to-guest communication > channels that bypass guest's network stack (don't require working networking in the guest). thanks. i had no idea that the existing console support required a networking stack; it works for the loader and i can watch the kernel load and initialize, so i always assumed it bypassed "networking". > But even for using it as the system console, it's a bit better than emulated serial port, because > the protocol supports passing console resize events from host to guest. nmdm could theoretically (as pty and pts both do) support TIOCGWINSZ and SIGWINCH, though? or perhaps bhyve's virtio_console device could offer pts(4) support? is the protocol spoken over the virtio_console socket documented online? i'd like to add support to rtty. currently i've been running the "resize" command at the guest shell, which feels very primitive. -- P Vixie From owner-freebsd-virtualization@freebsd.org Mon Jul 11 18:26:36 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 B565DB9244D for ; Mon, 11 Jul 2016 18:26:36 +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 7BF0F15D5 for ; Mon, 11 Jul 2016 18:26:36 +0000 (UTC) (envelope-from jakub.klama@uj.edu.pl) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII 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 <0OA5007HMXWA4K20@mta.uoks.uj.edu.pl> for freebsd-virtualization@freebsd.org; Mon, 11 Jul 2016 20:26:35 +0200 (CEST) Subject: Re: [Differential] D7185: Add virtio-console support to bhyve From: Jakub Klama In-reply-to: <5783E2FE.1040309@redbarn.org> Date: Mon, 11 Jul 2016 20:26:34 +0200 Cc: D7185+333+7754cf487cff2162@reviews.freebsd.org, freebsd-virtualization@freebsd.org Message-id: References: <5783D6FF.7010107@redbarn.org> <5783E2FE.1040309@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 18:26:36 -0000 > Jakub Klama wrote: >> The purpose of virtio-console is to create arbitrary bidirectional, host-to-guest communication >> channels that bypass guest's network stack (don't require working networking in the guest). > > thanks. i had no idea that the existing console support required a networking stack; it works for the loader and i can watch the kernel load and initialize, so i always assumed it bypassed "networking". > It didn't. What I meant is that virtio-console can be used as a replacement for TCP/IP communication between host and guest (at least in some applications). For example, it can be used by the "guest additions" code to talk to the host. >> But even for using it as the system console, it's a bit better than emulated serial port, because >> the protocol supports passing console resize events from host to guest. > > nmdm could theoretically (as pty and pts both do) support TIOCGWINSZ and SIGWINCH, though? or perhaps bhyve's virtio_console device could offer pts(4) support? Yeah, virtio_console totally deserves support for binding virtual console to a pty/pts. > is the protocol spoken over the virtio_console socket documented online? i'd like to add support to rtty. currently i've been running the "resize" command at the guest shell, which feels very primitive. Right now the socket just speaks raw data. It would need some multiplexing or ideally an IPC mechanism to send the resize events. Jakub From owner-freebsd-virtualization@freebsd.org Mon Jul 11 18:32:46 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 5FE4CB92820 for ; Mon, 11 Jul 2016 18:32:46 +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 4FCEE1DED for ; Mon, 11 Jul 2016 18:32:45 +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 6D5403AF8E; Mon, 11 Jul 2016 18:32:45 +0000 (UTC) Message-ID: <5783E64B.9010608@redbarn.org> Date: Mon, 11 Jul 2016 11:32:43 -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> 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: Mon, 11 Jul 2016 18:32:46 -0000 Jakub Klama wrote: > ... What I meant is that virtio-console can be used as a > replacement for TCP/IP communication between host and guest (at least in > some applications). For example, it can be used by the "guest additions" > code to talk to the host. so, kermit? :-) >> nmdm could theoretically (as pty and pts both do) support >> TIOCGWINSZ and SIGWINCH, though? or perhaps bhyve's virtio_console >> device could offer pts(4) support? > > Yeah, virtio_console totally deserves support for binding virtual > console to a pty/pts. layering wise, adding TIOCGWINSZ and SIGWINCH support to nmdm makes more sense than inventing another host-side protocol. as does adding pts(4) support to the virtio_console driver. are those things hard? >> is the protocol spoken over the virtio_console socket documented >> online? i'd like to add support to rtty. currently i've been >> running the "resize" command at the guest shell, which feels very >> primitive. > > Right now the socket just speaks raw data. It would need some > multiplexing or ideally an IPC mechanism to send the resize events. yikes. so you've got to reinvent what TIOCPKT does, but differently? -- P Vixie From owner-freebsd-virtualization@freebsd.org Mon Jul 11 18:36:39 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 AA6BFB928CD for ; Mon, 11 Jul 2016 18:36:39 +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 6BEB71E87 for ; Mon, 11 Jul 2016 18:36:39 +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 <0OA5007HWYD14K20@mta.uoks.uj.edu.pl> for freebsd-virtualization@freebsd.org; Mon, 11 Jul 2016 20:36:38 +0200 (CEST) Subject: Re: [Differential] D7185: Add virtio-console support to bhyve From: Jakub Klama In-reply-to: <5783E64B.9010608@redbarn.org> Date: Mon, 11 Jul 2016 20:36:37 +0200 Cc: freebsd-virtualization@freebsd.org Content-transfer-encoding: quoted-printable Message-id: <6B5AEBF8-98B0-4031-A3E3-A1EBC8B4B763@uj.edu.pl> References: <5783D6FF.7010107@redbarn.org> <5783E2FE.1040309@redbarn.org> <5783E64B.9010608@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 18:36:39 -0000 > Wiadomo=C5=9B=C4=87 napisana przez Paul Vixie w = dniu 11.07.2016, o godz. 20:32: >>> nmdm could theoretically (as pty and pts both do) support >>> TIOCGWINSZ and SIGWINCH, though? or perhaps bhyve's virtio_console >>> device could offer pts(4) support? >>=20 >> Yeah, virtio_console totally deserves support for binding virtual >> console to a pty/pts. >=20 > layering wise, adding TIOCGWINSZ and SIGWINCH support to nmdm makes = more sense than inventing another host-side protocol. as does adding = pts(4) support to the virtio_console driver. are those things hard? nmdm(4) emulates a serial port. how could one pass ioctls and signals = via serial port? >>> is the protocol spoken over the virtio_console socket documented >>> online? i'd like to add support to rtty. currently i've been >>> running the "resize" command at the guest shell, which feels very >>> primitive. >>=20 >> Right now the socket just speaks raw data. It would need some >> multiplexing or ideally an IPC mechanism to send the resize events. >=20 > yikes. so you've got to reinvent what TIOCPKT does, but differently? how could one pass ioctls via unix domain socket? Jakub= From owner-freebsd-virtualization@freebsd.org Mon Jul 11 21:52:25 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 8CC9DB92125 for ; Mon, 11 Jul 2016 21:52:25 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 4E7B01341 for ; Mon, 11 Jul 2016 21:52:25 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from iredmail.onthenet.com.au (iredmail.onthenet.com.au [203.13.68.150]) by alto.onthenet.com.au (Postfix) with ESMTPS id DB8D720A40C4 for ; Tue, 12 Jul 2016 07:52:16 +1000 (AEST) Received: from localhost (iredmail.onthenet.com.au [127.0.0.1]) by iredmail.onthenet.com.au (Postfix) with ESMTP id D1BCE2810BA for ; Tue, 12 Jul 2016 07:52:16 +1000 (AEST) X-Amavis-Modified: Mail body modified (using disclaimer) - iredmail.onthenet.com.au Received: from iredmail.onthenet.com.au ([127.0.0.1]) by localhost (iredmail.onthenet.com.au [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lbChwRffaV14 for ; Tue, 12 Jul 2016 07:52:16 +1000 (AEST) Received: from Peters-MacBook-Pro-2.local (unknown [96.82.80.65]) by iredmail.onthenet.com.au (Postfix) with ESMTPSA id A4CF2280901; Tue, 12 Jul 2016 07:52:13 +1000 (AEST) Subject: Re: [Differential] D7185: Add virtio-console support to bhyve To: Jakub Klama , Paul Vixie References: <5783D6FF.7010107@redbarn.org> Cc: freebsd-virtualization@freebsd.org From: Peter Grehan Message-ID: <18630e8f-6576-b613-1eae-07a00eca7b91@freebsd.org> Date: Mon, 11 Jul 2016 14:52:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=T//OdLCQ c=1 sm=1 tr=0 a=A6CF0fG5TOl4vs6YHvqXgw==:117 a=mwgbnDbW7alINpy3vhoKyg==:17 a=IkcTkHD0fZMA:10 a=cAmyUtKerLwA:10 a=NEAV23lmAAAA:8 a=ev7ODb581xfm2AbaXMQA:9 a=Bn2pgwyD2vrAyMmN8A2t:22 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:52:25 -0000 Hi Jakub, > The purpose of virtio-console is to create arbitrary bidirectional, > host-to-guest communication channels that bypass guest's network > stack (don't require working networking in the guest). Could virtio-vsock be a better solution for this ? Docker's hyperkit has an implementation, though it appears Linux guest support is very recent. https://github.com/docker/hyperkit/blob/af-vsock/src/pci_virtio_sock.c > But even for > using it as the system console, it's a bit better than emulated > serial port, because the protocol supports passing console resize > events from host to guest. It makes for an excellent serial port since it uses descriptor rings for data transfer, but the lack of a simple polled-mode operation (unless the emergency support is used) isn't the best for a system console. later, Peter. 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 From owner-freebsd-virtualization@freebsd.org Mon Jul 11 21:59:17 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 23B92B9230A for ; Mon, 11 Jul 2016 21:59:17 +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 E0A2017CE; Mon, 11 Jul 2016 21:59:16 +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 <0OA6007ZP7QQ4K20@mta.uoks.uj.edu.pl>; Mon, 11 Jul 2016 23:59:15 +0200 (CEST) Subject: Re: [Differential] D7185: Add virtio-console support to bhyve From: Jakub Klama In-reply-to: <18630e8f-6576-b613-1eae-07a00eca7b91@freebsd.org> Date: Mon, 11 Jul 2016 23:59:14 +0200 Cc: Paul Vixie , freebsd-virtualization@freebsd.org Content-transfer-encoding: quoted-printable Message-id: References: <5783D6FF.7010107@redbarn.org> <18630e8f-6576-b613-1eae-07a00eca7b91@freebsd.org> To: Peter Grehan 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 21:59:17 -0000 > Wiadomo=C5=9B=C4=87 napisana przez Peter Grehan w = dniu 11.07.2016, o godz. 23:52: >=20 > Hi Jakub, >=20 >> The purpose of virtio-console is to create arbitrary bidirectional, >> host-to-guest communication channels that bypass guest's network >> stack (don't require working networking in the guest). >=20 > Could virtio-vsock be a better solution for this ? Docker's hyperkit = has an implementation, though it appears Linux guest support is very = recent. > = https://github.com/docker/hyperkit/blob/af-vsock/src/pci_virtio_sock.c virtio-vsock is indeed nice, but guest support is virtually missing. = Also, I do think a simple, bidirectional host-to-guest pipe suits just = fine for most scenarios where hypervisor wants to control guest or vice = versa. Let's do simple things first. >> But even for >> using it as the system console, it's a bit better than emulated >> serial port, because the protocol supports passing console resize >> events from host to guest. >=20 > It makes for an excellent serial port since it uses descriptor rings = for data transfer, but the lack of a simple polled-mode operation = (unless the emergency support is used) isn't the best for a system = console. Let me put emergency write support in there. It's just few lines of = code. Jakub= 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= From owner-freebsd-virtualization@freebsd.org Tue Jul 12 00:39: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 3F507B92D34 for ; Tue, 12 Jul 2016 00:39:29 +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 2DC661F43 for ; Tue, 12 Jul 2016 00:39:28 +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 943863AF8E; Tue, 12 Jul 2016 00:39:27 +0000 (UTC) Message-ID: <57843C3D.80102@redbarn.org> Date: Mon, 11 Jul 2016 17:39:25 -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> In-Reply-To: <577FFDDF-7EC5-4143-AA1B-858BA8C3287F@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: Tue, 12 Jul 2016 00:39:29 -0000 Jakub Klama wrote: > 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 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. 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. > 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. 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. 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? -- P Vixie 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= 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 From owner-freebsd-virtualization@freebsd.org Tue Jul 12 09:19:03 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 97DF5B92D9E for ; Tue, 12 Jul 2016 09:19:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 8666519FA for ; Tue, 12 Jul 2016 09:19:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u6C9J3NR047643 for ; Tue, 12 Jul 2016 09:19:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-virtualization@FreeBSD.org Subject: [Bug 210425] [Hyper-V]"smartctl -i /dev/da0" on FreeBSD 10.3 on Windows 2010 & 2016 server caused disk detached Date: Tue, 12 Jul 2016 09:19:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: honzhan@microsoft.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-virtualization@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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 09:19:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210425 Hongjiang changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed --- Comment #2 from Hongjiang --- It has been fixed on head. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-virtualization@freebsd.org Tue Jul 12 12:28: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 EB559B9226C for ; Tue, 12 Jul 2016 12:28:57 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4EE521B99 for ; Tue, 12 Jul 2016 12:28:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA18772 for ; Tue, 12 Jul 2016 15:28:45 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bMwnt-000JCU-1h for freebsd-virtualization@freebsd.org; Tue, 12 Jul 2016 15:28:45 +0300 To: "freebsd-virtualization@freebsd.org" From: Andriy Gapon Subject: bhyve: disable msi and msix on virtio reset? Message-ID: <011771a3-8424-7810-d9db-870ddcea2448@FreeBSD.org> Date: Tue, 12 Jul 2016 15:27:22 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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 12:28:58 -0000 A write of a zero to VTCFG_R_STATUS initiates a virtio device reset via vc_reset. Typically this means a call to vi_reset_dev() which resets a bunch of fields in virtio_softc, but does not touch a corresponding pci_devinst (hanging off vs_pi) at all. Among other things this means that PCI MSI and MSI-X states remain unchanged. One of the consequences is that we keep using virtio_config_size of 24 if MSI-X is enabled. Should the virtio status reset also reset the PCI state? One practical problem that I see is with illumos fast reboot where the illumos virtio driver assumes that the status reset is sufficient to return a device to a state like after a clean (full) reboot. Thank you. -- Andriy Gapon From owner-freebsd-virtualization@freebsd.org Tue Jul 12 20:36:20 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 E56B0B2C008 for ; Tue, 12 Jul 2016 20:36:20 +0000 (UTC) (envelope-from tycho.nightingale@pluribusnetworks.com) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A78A91A79 for ; Tue, 12 Jul 2016 20:36:20 +0000 (UTC) (envelope-from tycho.nightingale@pluribusnetworks.com) Received: by mail-qt0-x22c.google.com with SMTP id 52so14855617qtq.3 for ; Tue, 12 Jul 2016 13:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pluribusnetworks.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w/0pKUB/Oux+BY6N7lNmD6UCBuQqO4Ps+M4K3bZje7I=; b=Oir1PEhfPfjjRIodjJkCuFPxxmNlwJHQhoouiLeGndC4FgK/WeBsDj0QLLE3VsyoUj einDzqcU1rP7DZvZE2zFBdKdpNSK7boOen5HwW/z097iofbhupJezvGWPAkhU9DpzBi+ WAOYwlKvZjSWs8Lz/FD2CJIQMrUIOFS+cSA5w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w/0pKUB/Oux+BY6N7lNmD6UCBuQqO4Ps+M4K3bZje7I=; b=Tz4lzMXjgk9+mG9zpHTWXUtLRKN4dUC+CcG/Wddo23cx3ALV6HcYl/y3Mr4kEtDZOo E0XqbOIIl9Efl/fc7VSTJdUoPt4762Jh8pA/jPT7J+fB5sv5FayMDWnJ1bdYNs+nw8qt n7lwqUUBK14qJSxC6B/Wcwth2Lxh6Y50Re6W8J5EWln5Hy70Gz6RQiY7Qzuis3g0EWsF xdCeJPpCZ6+tPJlfs54KVGnARRRf3yQdlLptUJKblXN8e/tq1Pso2QMPSZO2PtbyhhxD yrjyC9xRwmuB32BP6gPMkuqxZqe0CLgllFS+7Kv92v0ZpV3ednEBCyxrbL/pWFL5oFi1 HMyQ== X-Gm-Message-State: ALyK8tJ1L59j8kCWCfNateiUKgO/dn/jC3Ee9UHBnWqMFFqAw8KIuzTUbxLvxU3sUv0wr5r9 X-Received: by 10.200.52.43 with SMTP id u40mr6540515qtb.74.1468355779539; Tue, 12 Jul 2016 13:36:19 -0700 (PDT) Received: from [10.0.1.4] (209-6-121-211.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.121.211]) by smtp.gmail.com with ESMTPSA id n6sm2914560qke.31.2016.07.12.13.36.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Jul 2016 13:36:18 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: bhyve: disable msi and msix on virtio reset? From: Tycho Nightingale In-Reply-To: <011771a3-8424-7810-d9db-870ddcea2448@FreeBSD.org> Date: Tue, 12 Jul 2016 16:36:17 -0400 Cc: "freebsd-virtualization@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7D5D0A30-1ABA-49F6-83CC-6F398FC25B05@pluribusnetworks.com> References: <011771a3-8424-7810-d9db-870ddcea2448@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1878.6) 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 20:36:21 -0000 Hi, Yes, writing 0 to the status resister should reset the device including = all PCIE state. This implies that vi_reset_dev() needs to take the = proper actions to bring the associated pci_devinst (which from the = guest=92s perspective isn=92t a discrete element) back to it=92s reset = state too. Tycho On Jul 12, 2016, at 8:27 AM, Andriy Gapon wrote: >=20 > A write of a zero to VTCFG_R_STATUS initiates a virtio device reset = via > vc_reset. Typically this means a call to vi_reset_dev() which resets = a > bunch of fields in virtio_softc, but does not touch a corresponding > pci_devinst (hanging off vs_pi) at all. Among other things this means > that PCI MSI and MSI-X states remain unchanged. One of the = consequences > is that we keep using virtio_config_size of 24 if MSI-X is enabled. >=20 > Should the virtio status reset also reset the PCI state? >=20 > One practical problem that I see is with illumos fast reboot where the > illumos virtio driver assumes that the status reset is sufficient to > return a device to a state like after a clean (full) reboot. >=20 > Thank you. > --=20 > Andriy Gapon > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to = "freebsd-virtualization-unsubscribe@freebsd.org" From owner-freebsd-virtualization@freebsd.org Tue Jul 12 23:38:52 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 65B0CB97464 for ; Tue, 12 Jul 2016 23:38:52 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 1BD7F14BD for ; Tue, 12 Jul 2016 23:38:51 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from iredmail.onthenet.com.au (iredmail.onthenet.com.au [203.13.68.150]) by alto.onthenet.com.au (Postfix) with ESMTPS id CBD1420A40DA for ; Wed, 13 Jul 2016 09:38:43 +1000 (AEST) Received: from localhost (iredmail.onthenet.com.au [127.0.0.1]) by iredmail.onthenet.com.au (Postfix) with ESMTP id C60B0280F61 for ; Wed, 13 Jul 2016 09:38:43 +1000 (AEST) X-Amavis-Modified: Mail body modified (using disclaimer) - iredmail.onthenet.com.au Received: from iredmail.onthenet.com.au ([127.0.0.1]) by localhost (iredmail.onthenet.com.au [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Eei5crAuAJYa for ; Wed, 13 Jul 2016 09:38:43 +1000 (AEST) Received: from Peters-MacBook-Pro-2.local (unknown [96.82.80.65]) by iredmail.onthenet.com.au (Postfix) with ESMTPSA id 54F192809F2; Wed, 13 Jul 2016 09:38:41 +1000 (AEST) Subject: Re: bhyve: disable msi and msix on virtio reset? To: Tycho Nightingale , Andriy Gapon References: <011771a3-8424-7810-d9db-870ddcea2448@FreeBSD.org> <7D5D0A30-1ABA-49F6-83CC-6F398FC25B05@pluribusnetworks.com> Cc: "freebsd-virtualization@freebsd.org" From: Peter Grehan Message-ID: <22aa6570-6a2e-e5d6-1882-86b9ffcb15e7@freebsd.org> Date: Tue, 12 Jul 2016 16:38:45 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7D5D0A30-1ABA-49F6-83CC-6F398FC25B05@pluribusnetworks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=T//OdLCQ c=1 sm=1 tr=0 a=A6CF0fG5TOl4vs6YHvqXgw==:117 a=mwgbnDbW7alINpy3vhoKyg==:17 a=N659UExz7-8A:10 a=cAmyUtKerLwA:10 a=pZ2RuUnEugDbEFitAvsA:9 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 23:38:52 -0000 Hi Tycho, > Yes, writing 0 to the status resister should reset the device > including all PCIE state. This implies that vi_reset_dev() needs to > take the proper actions to bring the associated pci_devinst (which > from the guest=92s perspective isn=92t a discrete element) back to it=92= s > reset state too. I'm not sure if the reset also hits PCIe state, if you're counting=20 config space as part of that (e.g. BAR contents). As an example, the=20 FreeBSD guest virtio code doesn't do any config space saves/restores=20 around a reset. later, Peter. From owner-freebsd-virtualization@freebsd.org Wed Jul 13 00:21:06 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 4EAB7B97D3F for ; Wed, 13 Jul 2016 00:21:06 +0000 (UTC) (envelope-from tycho.nightingale@pluribusnetworks.com) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C57216EC for ; Wed, 13 Jul 2016 00:21:06 +0000 (UTC) (envelope-from tycho.nightingale@pluribusnetworks.com) Received: by mail-qk0-x229.google.com with SMTP id o67so29856246qke.1 for ; Tue, 12 Jul 2016 17:21:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pluribusnetworks.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zLkKuU6HJxBdSO5cg5BB3hpkIiYNm8WxnJH4wvDZNLM=; b=IqxfLVdgFMxme/kz4jIbBSjn0XzSMkyTSdKJbZksddElunEG0c+Wf42C3wikkteIVG Zy2XBcWyLgtgTN6ihv147JiYSTb1igCtvvVLjQH+ZPV18uHlku2cN++Wga+lP1ZSViSy 00L7kgp7dQ8AD0m73OMrjUhGFDH1BNMw35E0w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zLkKuU6HJxBdSO5cg5BB3hpkIiYNm8WxnJH4wvDZNLM=; b=SMgQOPi4eAKnXz5MsQN13f4gj7M8HrHFKv1u1on5aZXV9TFvw7oa8XmcGemnFSdl8J 0LHXkGKGz7SDG+gSSdrRwM26FAm/8Vchfa8dsqxcqqYSXG+9Eci2Z6V5fBBm9DZFLjAV 5pDlkOlBXVajFVMF1gBdlvk46WpiLw4kd5UR4FsSPuvA3qlNF/s9uzJwKUvdLvZrL6BO 0hYMDh/lXyhYnsGOGTJUY5R5YNSpESCKRbJWJfS6uVqOlh6sgId8I29s7jf+raZViXm+ L+F9Y1TQGGbiInIKTEpqmNIhoewFip6WMhzJy8uPKcNYO8n5VZ4LPRYOrw4z+wQA6kxG N0Bg== X-Gm-Message-State: ALyK8tK+6H98mJhgSxIpCyDFx65mRUFyONPuW7OYJaKBHW6PfoluxsPcVW++1Msy+KKDFasu X-Received: by 10.233.216.133 with SMTP id u127mr6908976qkf.203.1468369265103; Tue, 12 Jul 2016 17:21:05 -0700 (PDT) Received: from [10.0.1.4] (209-6-121-211.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.121.211]) by smtp.gmail.com with ESMTPSA id 23sm321216qki.1.2016.07.12.17.21.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Jul 2016 17:21:04 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: bhyve: disable msi and msix on virtio reset? From: Tycho Nightingale In-Reply-To: <22aa6570-6a2e-e5d6-1882-86b9ffcb15e7@freebsd.org> Date: Tue, 12 Jul 2016 20:21:02 -0400 Cc: Andriy Gapon , "freebsd-virtualization@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6D0C5EB5-0983-4D4C-A8EE-18254E56C557@pluribusnetworks.com> References: <011771a3-8424-7810-d9db-870ddcea2448@FreeBSD.org> <7D5D0A30-1ABA-49F6-83CC-6F398FC25B05@pluribusnetworks.com> <22aa6570-6a2e-e5d6-1882-86b9ffcb15e7@freebsd.org> To: Peter Grehan X-Mailer: Apple Mail (2.1878.6) 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: Wed, 13 Jul 2016 00:21:06 -0000 Hi, On Jul 12, 2016, at 7:38 PM, Peter Grehan wrote: >> Yes, writing 0 to the status resister should reset the device >> including all PCIE state. This implies that vi_reset_dev() needs to >> take the proper actions to bring the associated pci_devinst (which >> from the guest=92s perspective isn=92t a discrete element) back to = it=92s >> reset state too. >=20 > I'm not sure if the reset also hits PCIe state, if you're counting = config space as part of that (e.g. BAR contents). As an example, the = FreeBSD guest virtio code doesn't do any config space saves/restores = around a reset. This is one of those ambiguities in the virtio spec wherein the = canonical implementation (qemu) becomes the de facto standard. I see in = illumos driver that only a virtio-reset is performed in the quiesce = entry point. On qemu Is this sufficient on qemu to support warm rest? = If so then perhaps we should only clear the capabilities (MSIX) and not = the BARs. Tycho= From owner-freebsd-virtualization@freebsd.org Wed Jul 13 22:37:27 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 BCF87B98D8B for ; Wed, 13 Jul 2016 22:37:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 ABE3D19DD for ; Wed, 13 Jul 2016 22:37:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u6DMbRlp098604 for ; Wed, 13 Jul 2016 22:37:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-virtualization@FreeBSD.org Subject: [Bug 203682] Slow boot under VMware Fusion w/ UEFI firmware and SMP -- until APs are launched Date: Wed, 13 Jul 2016 22:37:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-virtualization@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Wed, 13 Jul 2016 22:37:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203682 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|emulation@FreeBSD.org |freebsd-virtualization@Free | |BSD.org --- Comment #2 from Mark Linimon --- Fix assignment. --=20 You are receiving this mail because: You are the assignee for the bug.=