How do single step events work?

180 views
Skip to first unread message

D'Mita Levy

unread,
Mar 23, 2017, 9:34:05 PM3/23/17
to vmitools
I don't understand how single step events work...what is actually happening? Is the machine just going to the next instruction and then there is a callback. Also, what does return (1u << VMI_EVENT_RESPONSE_TOGGLE_SINGLESTEP) actually do? I read the documentation in events.h but what is it toggling exactly? Does it mean that from that point on every one machine instruction will end up triggering a callback? 

Steven Maresca

unread,
Mar 23, 2017, 10:38:09 PM3/23/17
to vmit...@googlegroups.com
What toggle facilitates is essentially equivalent to a 'step once' feature in a debugger.

Single stepping in a virtual context is similar to native operation. Normally in an x86 baremetal context, single stepping is facilitated by setting the TF (trap flag) bit is set in the FLAGS register. Each instruction execution causes the delivery of an interrupt that must be handled by whatever is running on the CPU, like a kernel and a debugger.

In a virtualized scenario, things need to operate a bit differently: a hypervisor will itself receive the interrupt, rather than the kernel supervising the executing application.  Single step execution occurs when the monitor trap flag (MTF) is set in the control structure representing a vCPU.  When the MTF is set, a VM exit will immediately occur after entry on instruction boundaries.  That notification may be conveyed out of the hypervisor If a facility like LibVMI is in use.

If the flag is not toggled, execution will never advance past the faulting instruction.

Steve

On Thu, Mar 23, 2017 at 9:34 PM, D'Mita Levy <dlev...@fiu.edu> wrote:
I don't understand how single step events work...what is actually happening? Is the machine just going to the next instruction and then there is a callback. Also, what does return (1u << VMI_EVENT_RESPONSE_TOGGLE_SINGLESTEP) actually do? I read the documentation in events.h but what is it toggling exactly? Does it mean that from that point on every one machine instruction will end up triggering a callback? 

--
You received this message because you are subscribed to the Google Groups "vmitools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vmitools+unsubscribe@googlegroups.com.
To post to this group, send email to vmit...@googlegroups.com.
Visit this group at https://groups.google.com/group/vmitools.
For more options, visit https://groups.google.com/d/optout.

Tamas K Lengyel

unread,
Mar 24, 2017, 1:26:13 PM3/24/17
to vmit...@googlegroups.com
To correct some of what Steve said, when you have the mtf bit turned on the system will advance to the next instruction automatically after it returns from the callback. You don't have to clear it for that to happen.

Robert Yates

unread,
Mar 24, 2017, 2:09:00 PM3/24/17
to vmitools
actually i have some questions about single stepping, its not always clear to me when to use what.

When would you return VMI_EVENT_RESPONSE_TOGGLE_SINGLESTEP from an event? since you cannot assign a callback
to this return statement, maybe only instead of a clear inside an already executing step handler?

If you are inside an interrupt event then you simply use the reject options,
if you are inside a memory event then i would clear then use vmi_step_event() with a steps
value of 1 and my steps-callback which doesnt need to clear this event.

P.S: where can i find information on VMI_EVENT_RESPONSE_EMULATE, i tried this once and it just crashed
and VMI_EVENT_RESPONSE_SET_REGISTERS appears to update the context from the event registers

P.P.S: am i using it wrong when i say return VMI_EVENT_RESPONSE_EMULATE; should it be return 1 << VMI_EVENT_RESPONSE_EMULATE;#


On Friday, March 24, 2017 at 6:26:13 PM UTC+1, Tamas K Lengyel wrote:
To correct some of what Steve said, when you have the mtf bit turned on the system will advance to the next instruction automatically after it returns from the callback. You don't have to clear it for that to happen.
On Mar 23, 2017 8:38 PM, "Steven Maresca" <steve....@gmail.com> wrote:
What toggle facilitates is essentially equivalent to a 'step once' feature in a debugger.

Single stepping in a virtual context is similar to native operation. Normally in an x86 baremetal context, single stepping is facilitated by setting the TF (trap flag) bit is set in the FLAGS register. Each instruction execution causes the delivery of an interrupt that must be handled by whatever is running on the CPU, like a kernel and a debugger.

In a virtualized scenario, things need to operate a bit differently: a hypervisor will itself receive the interrupt, rather than the kernel supervising the executing application.  Single step execution occurs when the monitor trap flag (MTF) is set in the control structure representing a vCPU.  When the MTF is set, a VM exit will immediately occur after entry on instruction boundaries.  That notification may be conveyed out of the hypervisor If a facility like LibVMI is in use.

If the flag is not toggled, execution will never advance past the faulting instruction.

Steve
On Thu, Mar 23, 2017 at 9:34 PM, D'Mita Levy <dlev...@fiu.edu> wrote:
I don't understand how single step events work...what is actually happening? Is the machine just going to the next instruction and then there is a callback. Also, what does return (1u << VMI_EVENT_RESPONSE_TOGGLE_SINGLESTEP) actually do? I read the documentation in events.h but what is it toggling exactly? Does it mean that from that point on every one machine instruction will end up triggering a callback? 

--
You received this message because you are subscribed to the Google Groups "vmitools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vmitools+u...@googlegroups.com.

To post to this group, send email to vmit...@googlegroups.com.
Visit this group at https://groups.google.com/group/vmitools.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "vmitools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vmitools+u...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages