Hypervisor trace events

Most qvm trace events are Class 10 events. However, some qvm threads may also make kernel calls to the hypervisor microkernel; these will have corresponding kernel call events.

The following should help you interpret the data provided with Class 10 events from a hypervisor host.

ID 0 — guest entry

The guest is executing code at guest_ip address.

Arguments:

guest_ip
The execution address, as seen by the guest.

ID 1 — guest exit

The guest has stopped executing code.

Arguments:

status
Architecture-specific. On x86 platforms, a non-zero ID 1 status field indicates that the guest entry was aborted before guest was able to run.
reason
Architecture-specific.
clockcycles_offset
Offset between guest view of timestamp and host view of timestamp. Measured in clock cycles (see ClockCycles() in the C Library Reference). A negative number means the guest is behind the host; a positive number means the guest is ahead of the host.
On x86 platforms, if the status field is non-zero, the guest didn't run, so the value of clockcycles_offset is stale (and therefore meaningless).
guest_ip
The execution address, as seen by the guest.
hw_payload
Architecture-specific.
Note: For both ARM and x86 platforms, to know if the guest actually ran before it exited, check for the presence of ID 7 events between the ID 0 and ID 1 events (see “ID 7 — provide guest clock cycle information for guest entry and exit” below). If no ID 7 events are present, then the guest didn't run.

ID 2 — create a vCPU thread

A virtual CPU (vCPU) thread has been created to schedule the vCPU.

Occurs only once per vCPU in the lifetime of a qvm process instance. If you start your trace after the qvm process has started, you won't see these events.

Arguments:

vcpu_id
vCPU-specific ID internal to hypervisor. The ID number as seen in the trace logs will be marked as virtual cpu num, where num is the vCPU number, starting at 0 (zero).

ID 3 — assert an interrupt to a guest CPU

An interrupt has been asserted on a vCPU (seen by the guest as a CPU). The VM (qvm process instance) in which the guest is running must be configured to deliver the interrupt to the guest. This configuration is specified in the *.qvmconf file for the qvm process instance.

Arguments:

vcpu_id
ID of the vCPU where the interrupt is being asserted.
interrupt
The interrupt as seen by the guest (e.g., on x86-64 platforms, a vector number).

ID 4 — de-assert an interrupt to a guest CPU

An interrupt is being de-asserted on a vCPU (seen by the guest as a CPU).

Arguments:

vcpu_id
ID of the vCPU where the interrupt is being de-asserted.
interrupt
The interrupt as seen by the guest (e.g., on x86-64 platforms, a vector number).

ID 5 — create a virtual timer

A timer has been created for a vCPU.

Occurs only once per timer in the lifetime of a qvm process instance. If you start your trace after the qvm process has started, you may not see these events.

Arguments:

timer_id
The value returned by timer_create(), which has been called by the qvm process instance.
cpu_id
The ID of the vCPU where the timer was created.

ID 6 — trigger a virtual timer

A virtual timer has been triggered.

Argument:

timer_id
The ID of the vCPU where the timer was triggered.

ID 7 — provide guest clock cycle information for guest entry and exit

Guest clock cycle values at guest entry and exit.

Arguments:

at_entry
The guest clock cycles value at guest entry.
at_exit
The guest clock cycles value at guest exit.

Kernel call events

The kernel calls you will see in trace logs for a hypervisor host will also include events that are not specific to the hypervisor, such as MMap and MMunmap. See your System Analysis Toolkit User's Guide for more information about kernel call trace events.