Date: Mon, 18 Aug 2014 20:59:28 -0700 From: Neel Natu <neelnatu@gmail.com> To: Martin Steegmanns <martin@unix-users.de> Cc: "freebsd-virtualization@freebsd.org" <freebsd-virtualization@freebsd.org> Subject: Re: Problem with vmexit on mtrap Message-ID: <CAFgRE9GSzAAMojX4ZZ13VV3GpUjiAX4DWDu5NNeCr2kwZYyQfQ@mail.gmail.com> In-Reply-To: <20140816193345.GC5519@mail.demonism.de> References: <20140812092407.GC11403@mail.demonism.de> <CAFgRE9GEXfXbiUjW-dJB7u5Bdqp7sE7k4L1fKmrT8n8OJt19oQ@mail.gmail.com> <20140816193345.GC5519@mail.demonism.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Martin, On Sat, Aug 16, 2014 at 12:33 PM, Martin Steegmanns <martin@unix-users.de> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFgRE9GSzAAMojX4ZZ13VV3GpUjiAX4DWDu5NNeCr2kwZYyQfQ>