From owner-freebsd-virtualization@FreeBSD.ORG Sat Nov 8 17:57:21 2014 Return-Path: Delivered-To: virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFC629CE for ; Sat, 8 Nov 2014 17:57:21 +0000 (UTC) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 718E1A0A for ; Sat, 8 Nov 2014 17:57:21 +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 E9CC81248B; Sun, 9 Nov 2014 03:57:13 +1000 (EST) Received: from Peter-Grehans-MacBook-Pro-2.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 BZP03625 (AUTH peterg@ptree32.com.au); Sun, 9 Nov 2014 03:57:12 +1000 Message-ID: <545E5978.2010900@freebsd.org> Date: Sat, 08 Nov 2014 09:57:12 -0800 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Marcel Moolenaar Subject: Re: [current] bhyve under VMware borked? References: <3054C397-B9F4-44A7-8D71-FF83CB058671@mac.com> <545D160E.7060208@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Sat, 08 Nov 2014 17:57:21 -0000 Hi Marcel, >> What version of VMWare and host are you using ? > > This is VMware Fusion 6.0.5 (2209127) running on Mac OS X 10.10. Ok, looks like the problem still exists in the wild :( Fusion 7 doesn't have this issue so there's always the upgrade option :) > Ok. If we don't depend on PAT-related exits, then I definitely would > appreciate preserving the -stable behaviour. Maybe we should not check > for the PAT-related exists in the first place? I mean if we don't need > them or depend on them to be there at all... bhyve does depend on h/w save/restore of the PAT MSR, and this is the case for all bare metal that is supported. For the nested case, bhyve used to trap/emulate PAT MSR accesses and not propagate them to the host. I'll look at resurrecting that code. later, Peter.