From owner-freebsd-virtualization@freebsd.org Thu Aug 16 16:01:28 2018 Return-Path: Delivered-To: freebsd-virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87E69106BF61 for ; Thu, 16 Aug 2018 16:01:28 +0000 (UTC) (envelope-from matt.churchyard@userve.net) Received: from smtp-a.userve.net (smtp-outbound.userve.net [217.196.1.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.userve.net", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 291B78A0B5 for ; Thu, 16 Aug 2018 16:01:28 +0000 (UTC) (envelope-from matt.churchyard@userve.net) Received: from owa.usd-group.com (owa.usd-group.com [217.196.1.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-a.userve.net (Postfix) with ESMTPS id B927AA8; Thu, 16 Aug 2018 17:01:26 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=userve.net; s=201508; t=1534435286; bh=CfdaF1e1ERpds6/QEDhPq+giq2RYP7T8lyrLeLT9eDk=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=HXu5153AVe59TFPUa6/isQva1jOMOwDLkydSbq+KNNPmpsSoe7jRr0ZD/zaim8p42 AhfDqEh2C5P2pL0J8K1czHpkM6EGWC3IdqR4R7zuLY0EDHOp4cBd2hW06Lxw0gQxH3 AQcHWOwtEhiptIRYtKWV0gy3hO4Ib1KZ8LeHXwOk= Received: from SERVER.ad.usd-group.com (192.168.0.1) by SERVER.ad.usd-group.com (192.168.0.1) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 16 Aug 2018 17:01:26 +0100 Received: from SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9]) by SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9%12]) with mapi id 15.00.0847.030; Thu, 16 Aug 2018 17:01:26 +0100 From: Matt Churchyard To: "Rodney W. Grimes" CC: "freebsd-virtualization@freebsd.org" Subject: RE: Checking bhyve supported features (sysctls) Thread-Topic: Checking bhyve supported features (sysctls) Thread-Index: AdQ1Sj/JzUfq4S8/RYq4DRXDNWTckQAIYkuAAANnXRA= Date: Thu, 16 Aug 2018 16:01:25 +0000 Message-ID: <60d0e18d1ba34632aa6045c85c023bbd@SERVER.ad.usd-group.com> References: <3393f8f3d32a4f0890aab87185fbed01@SERVER.ad.usd-group.com> <201808161516.w7GFGtN1054010@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201808161516.w7GFGtN1054010@pdx.rh.CN85.dnsmgr.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.27 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: Thu, 16 Aug 2018 16:01:28 -0000 > Hello, >=20 > I'm looking for better ways to check for bhyve support / available featur= es without trying to scan through dmesg output. >Yes, it would be very good to remove that, as it usually tries to grep a n= on-existent file /var/run/dmesg.boot that is not created until after vm_bhy= ve has been called from /usr/local/etc/rc.d when you have things set to aut= ostartup >in /etc/rc.conf >=20 > I notice that the following 2 sysctl's appear to be set to 1 as soon=20 > as the vmm module is loaded >=20 > hw.vmm.vmx.initialized: 1 > hw.vmm.vmx.cap.unrestricted_guest: 1 >=20 > Will these be available on both Intel & AMD processors as a way to determ= ine if the module has loaded successfully and can run guests? >=20 > I also see the below sysctl related to iommu. >=20 > hw.vmm.iommu.initialized >=20 > Again, will this be set to 1 as soon as the module is loaded if iommu is = supported, or only when it is used? > There also seems to be a vmm.amdvi.enable sysctl. Would both these need c= hecking or is vmm.iommu enough to determine support on any processor. >Probalby the safest way for a shell script to decide if bhyve is up and ru= nning is to stat /dev/vmm, if that exists then the modules have loaded and = initialized and bhyve should be ready to process guests. Hmm, I don't get /dev/vmm unless I actually have running guests. >sysctl's mentiond above would be a poor way to make this determination. It would be nice if sysctls were better documented. If vmx.initialized is s= et once vmm has successfully loaded, I can't see a better way of checking f= or bhyve support (assuming it's not Intel specific). This entry definitely = exists and is set to 0 if you load the module on a non-supported system, an= d set to 1 as soon as vmm loads on my Intel test system. Matt --=20 Rod Grimes rgrimes@freebsd.= org