From owner-freebsd-virtualization@FreeBSD.ORG Tue Aug 19 03:59:29 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 8FECFC37 for ; Tue, 19 Aug 2014 03:59:29 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5142339AE for ; Tue, 19 Aug 2014 03:59:29 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id a108so5408134qge.38 for ; Mon, 18 Aug 2014 20:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K2k4Yf0yyvui1k2/v6eWN/GvqL4A25s43WUd1BAhhhM=; b=TB+BIh2bO5yyhsFvZXKVdipW+yj4stMKXyQ3sL86CXpv7kaIUXbL7dhhLlwtZr3yfS lta177ZDIp69quYwwWHW4HyEzImh+7lNry0H3/jHIOOaT7DqEO3sGph1ZfnjSqxwKRO8 hjF01n3nWsISb4vgXV3mWj3BaccPsFHt1yfRociXpf1Z6lvmLH2jiXR9q2mAvK/OSfEr Z2ni7LgwMdWfXohltbDfWf6BAN+Y31au/4x4BFZIj94TJXWp81N29wa8VM8T8pyhL46t ge6pxeNLaVcfYwd/SBOBjF2d9mrBTRaQrK/uIkUke0SX0YRaSOsE0I7A9nnrgW88/uBz R09w== MIME-Version: 1.0 X-Received: by 10.224.104.1 with SMTP id m1mr64079311qao.81.1408420768344; Mon, 18 Aug 2014 20:59:28 -0700 (PDT) Received: by 10.140.84.80 with HTTP; Mon, 18 Aug 2014 20:59:28 -0700 (PDT) In-Reply-To: <20140816193345.GC5519@mail.demonism.de> References: <20140812092407.GC11403@mail.demonism.de> <20140816193345.GC5519@mail.demonism.de> Date: Mon, 18 Aug 2014 20:59:28 -0700 Message-ID: Subject: Re: Problem with vmexit on mtrap From: Neel Natu To: Martin Steegmanns Content-Type: text/plain; charset=UTF-8 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: Tue, 19 Aug 2014 03:59:29 -0000 Hi Martin, On Sat, Aug 16, 2014 at 12:33 PM, Martin Steegmanns wrote: > 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 :). > On my Xeon E5-2650 running at 2.0GHz a single vcpu VM is still not at the login prompt after 7+ hours with MTRAP enabled. However, it is making forward progress and is chugging through the /etc/rc startup scripts very slowly. best Neel > Regards, > Martin