From owner-freebsd-virtualization@FreeBSD.ORG Sun Nov 23 03:57:12 2014 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6C1D230 for ; Sun, 23 Nov 2014 03:57:12 +0000 (UTC) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id A4976DF2 for ; Sun, 23 Nov 2014 03:57:12 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTP id 9942412179; Sun, 23 Nov 2014 13:57:10 +1000 (EST) Received: from Peters-MacBook-Pro.local (c-67-161-27-37.hsd1.ca.comcast.net [67.161.27.37]) by dommail.onthenet.com.au (MOS 4.4.4-GA) with ESMTP id BZX17768 (AUTH peterg@ptree32.com.au); Sun, 23 Nov 2014 13:57:09 +1000 Message-ID: <54715B13.9020303@freebsd.org> Date: Sat, 22 Nov 2014 19:57:07 -0800 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Shawn Webb Subject: Re: bhyve cannot allocate memory References: <20141122215245.d9380cc4e43cb5e60d479009@gmail.com> <20141122220202.09523b0ae828993174af05d8@gmail.com> <5471513C.6040400@freebsd.org> <54715438.3090905@freebsd.org> <54715822.2010309@freebsd.org> <54715911.1090100@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Nov 2014 03:57:13 -0000 Hi Shawn, > Interesting. I'll have to do more digging. Because removing map_at_zero > support is the same as keeping it at the default of 0. It's not possible > that our ASLR implementation is affecting bhyve, since our ASLR > implementation is in sys_mmap and the elf image activator. At this > stage, bhyve's vmm.ko is directly accessing vm_map_*, which we haven't > touched. One thing you may be able to try is ktrace the bhyveload process and see which syscall is failing. later, Peter.