From owner-freebsd-virtualization@FreeBSD.ORG Sat Aug 16 19:33:56 2014 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A01E1FA for ; Sat, 16 Aug 2014 19:33:56 +0000 (UTC) Received: from srv1.unix-users.de (srv1.unix-users.de [81.20.131.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.unix-users.de", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E30A2EBD for ; Sat, 16 Aug 2014 19:33:54 +0000 (UTC) Received: from localhost (bchm-4db63574.pool.mediaWays.net [77.182.53.116]) (authenticated bits=0) by srv1.unix-users.de (8.14.9/8.14.5) with ESMTP id s7GJXjej010834 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Sat, 16 Aug 2014 21:33:46 +0200 (CEST) (envelope-from martin@unix-users.de) X-Authentication-Warning: srv1.unix-users.de: Host bchm-4db63574.pool.mediaWays.net [77.182.53.116] claimed to be localhost Date: Sat, 16 Aug 2014 21:33:45 +0200 From: Martin Steegmanns To: Neel Natu Subject: Re: Problem with vmexit on mtrap Message-ID: <20140816193345.GC5519@mail.demonism.de> References: <20140812092407.GC11403@mail.demonism.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (srv1.unix-users.de [81.20.131.154]); Sat, 16 Aug 2014 21:33:46 +0200 (CEST) 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: Sat, 16 Aug 2014 19:33:56 -0000 On Tue, Aug 12, 2014 at 06:39:18PM -0700, Neel Natu wrote: > The VM-exit instruction length field is valid only for a subset of VM > exits. See section 27.2.4 "Information for VM exits due to instruction > execution" in the Intel SDM. > > In particular, the instruction length is not guaranteed to be valid if > the VM-exit is due to a hardware exception. Therefore it cannot be > used to "skip over" the UD2 instruction. > > On my machine the VM-exit instruction length field was set to '2' for > the first UD2 and '5' for the second UD2. OK, thx for the clarification. > For this specific test, you can either hardcode the instruction length > to '2' if the VM exit is due to a UD2 or use an instruction like "OUT" > to a specific I/O port to trigger the monitor-trap-flag on and off. A > VM-exit due to "OUT" will have the correct value in the VM-exit > instruction length field. But this "instruction length" issue only affects my way to toggle the MTF bit. The MTF itself does not rely internally on the "instruction length" field, or does it? As far as I understand, bhyve does not need a valid instruction length for MTF, because the handler returns VMEXIT_RESTART. No need for bhyve to adjust the rip on vmentry. If I set the MTF bit via bhyvectl, the guest system still seems to enter a loop. My mtrap handler writes the RIP to a file, but all I see are high addresses e.g: 0xffffffff806bf0b0 Xapic_isr1 According to kdb, these are addresses point to Xapic_isr1 and interrupt handlers. I wonder if a vmexit caused by the MTF could overlay with another vmexit. With the MTF bit set, I expect the guest system to behave exactly as without the MTF bit. Of course slower due to single stepping :). Regards, Martin