Problem with vmexit on mtrap

Neel Natu neelnatu at
Tue Aug 19 03:59:29 UTC 2014

Hi Martin,

On Sat, Aug 16, 2014 at 12:33 PM, Martin Steegmanns
<martin at> 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.


> Regards,
> Martin

More information about the freebsd-virtualization mailing list