Re: Problem with vmexit on mtrap
On Mon, Aug 18, 2014 at 08:59:28PM -0700, Neel Natu wrote: 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. Thank you! I assumed malfunction because I did no expect it to be that slow. 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
Re: Problem with vmexit on mtrap
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: 0x806bf0b0 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
Re: Problem with vmexit on mtrap
Hi Martin, On Tue, Aug 12, 2014 at 2:24 AM, Martin Steegmanns mar...@unix-users.de wrote: Hello list! I modified bhyve to toggle the MTF bit on an UD2 instruction. In a guest system, a program does: __asm__ __volatile__( UD2 NOP xor %rax,%rax NOP UD2 ); On the first UD2, MTF bit is correctly set, but the second UD2 is never reached (waited some hours). If I manually reset the MTF bit via bhyvectl --setcap, guest executione reaches the second UD2 instruction. A diff of my modifications is attached to this mail. Am I missing something on vmenter that makes the guest loop forever? 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. 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. best Neel Regards, Martin snippet of ktr dump /usr/src/sys/modules/vmm/../../amd64/vmm/intel/vmx.c:1074 vm vm1[0]: unhandled mtf vmexit at 0x804dde70 /usr/src/sys/modules/vmm/../../amd64/vmm/intel/vmx.c:1063 vm vm1[0]: Resume execution at 0x804dde41 /usr/src/sys/modules/vmm/../../amd64/vmm/intel/vmx.c:2652 vm vm1[0]: returning from vmx_run: exitcode 6 /usr/src/sys/modules/vmm/../../amd64/vmm/intel/vmx.c:1074 vm vm1[0]: unhandled mtf vmexit at 0x804dde41 /usr/src/sys/modules/vmm/../../amd64/vmm/intel/vmx.c:1063 vm vm1[0]: Resume execution at 0x804dde39 /usr/src/sys/modules/vmm/../../amd64/vmm/intel/vmx.c:2652 vm vm1[0]: returning from vmx_run: exitcode 6 /usr/src/sys/modules/vmm/../../amd64/vmm/intel/vmx.c:1074 vm vm1[0]: unhandled mtf vmexit at 0x804dde39 /usr/src/sys/modules/vmm/../../amd64/vmm/intel/vmx.c:1063 vm vm1[0]: Resume execution at 0x804dde30 /usr/src/sys/modules/vmm/../../amd64/vmm/intel/vmx.c:2652 vm vm1[0]: returning from vmx_run: exitcode 6 /usr/src/sys/modules/vmm/../../amd64/vmm/intel/vmx.c:1074 vm vm1[0]: unhandled mtf vmexit at 0x804dde30 /usr/src/sys/modules/vmm/../../amd64/vmm/intel/vmx.c:1063 vm vm1[0]: Resume execution at 0x804dde27 /usr/src/sys/modules/vmm/../../amd64/vmm/intel/vmx.c:2652 vm vm1[0]: returning from vmx_run: exitcode 6 /usr/src/sys/modules/vmm/../../amd64/vmm/intel/vmx.c:1074 vm vm1[0]: unhandled mtf vmexit at 0x804dde27 /usr/src/sys/modules/vmm/../../amd64/vmm/intel/vmx.c:1063 vm vm1[0]: Resume execution at 0x804dde1f /snippet ___ 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 ___ 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
