Hi Martin, On Sat, Aug 16, 2014 at 12:33 PM, Martin Steegmanns <mar...@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 _______________________________________________ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
