From owner-freebsd-virtualization@FreeBSD.ORG Mon Jun 22 16:18:38 2015 Return-Path: Delivered-To: freebsd-virtualization@nevdull.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 3CDD7499 for ; Mon, 22 Jun 2015 16:18:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 39FD4855; Mon, 22 Jun 2015 16:18:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA29546; Mon, 22 Jun 2015 19:18:35 +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 1Z74Qd-0005K5-89; Mon, 22 Jun 2015 19:18:35 +0300 Message-ID: <55883537.3030400@FreeBSD.org> Date: Mon, 22 Jun 2015 19:17:59 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Peter Grehan CC: "freebsd-virtualization@freebsd.org" Subject: Re: dtrace fbt vs vmm References: <5588317C.8020203@FreeBSD.org> <558832E8.9080407@freebsd.org> In-Reply-To: <558832E8.9080407@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.20 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, 22 Jun 2015 16:18:38 -0000 On 22/06/2015 19:08, Peter Grehan wrote: > Hi Andriy, > >> I haven't investigated this issue further, but if there are any unsafe functions >> in vmm it would be nice to blacklist them in the fbt code. >> Perhaps blacklisting everything from vmm module could be a stopgap solution. > > Intel or AMD ? We've been able to run dtrace on Intel; less (to no) coverage on > AMD so there's quite possibly bugs there. Peter, it's AMD again. Thanks! -- Andriy Gapon