[Xen-devel] [RFC PATCH 0/4] Introduce Single-Stepping to ARMv8

[Sergej Proskurin <proskurin@xxxxxxxxxxxxx>]

Hi all,

This patch series introduces support for single-stepping of guest VMs on
ARMv8. For detailed information about the single-stepping mechanism on
ARMv8, we refer the reader to ARM DDI 0487B.a Section D2.12 (Software
Step exceptions).

Our current implementation supports a rudimentary single-stepping
functionality of the guest's kernel executing in EL1 and is by no means
complete. While the hardware architecture also allows to single-step
EL2, we do not yet implement this feature. Another limitation is that
the current implementation does not yet support single-stepping over
load-exclusive/store-exclusive instructions (LDAXR/STXR), as noticed by
James Morse [0].

This patch series has been submitted as an RFC patch in order to discuss
potential implementation flaws. In the following, we describe the test
environment and appeared effects, the solution to which we would like to
find out.

Our general idea is to make use of the single-stepping functionality as
a means for tracing the guest kernel, executing in EL1. Therefore, we
would like to inject SMC instructions to desired locations within the
guest kernel's text segment. That is, upon execution of injected SMC
instructions, the guest would trap into the hypervisor, where we can
trace the trapping event. While trapped in the hypervisor, we would like
to replace the previously injected SMC with the original instruction (as
to ensure correct guest execution), single-step this original
instruction, and finally place back the SMC instruction before we
continue guest execution.

Our test case is a simple kernel module, which we inject inside of the
guest. Upon trapping the SMC instruction in Xen, we activate
single-stepping and increase the guest's PC by four to continue
execution.  Now, the issue that we are experiencing is that upon
execution of the SMC instruction, the guest seems to trap into a
synchronous interrupt handler. That is, the next guest instruction that
generates a software step exception is the first instruction of the
interrupt handler; not the next instruction (if we increase the pc by
four). This is deterministic and independent of whether we increment the
PC by four or not (to the instruction following the trapping SMC
instruction). As a result, because of the fact that the guest handles
the interrupt, we cannot single-step the replaced original instruction
until the interrupt handler finishes.

Our tests have shown that before the guest (that is currently configured
to use only one VCPU) generates a software step exception that traps
into the hypervisor at do_trap_guest_sync, the hypervisor interrupts the
guest and executes the handler do_trap_irq. We believe that the
interrupt gets injected by Xen into the guest (e.g., timer interrupt).
Which is the reason, why the next instruction that generates a software
step exception resides in the interrupt handler routine. This happens
deterministically every time the SMC gets executed.

We would like to understand if and how we can suspend guest interrupt
injections (if this is truly the cause of our problems), as long as we
are single-stepping the guest, without causing issues. This approach
would prevent SMC instructions to be followed by an in-guest interrupt
handling procedure and thus facilitate our use case.

It would be of great help if we would discuss the upper issue and
hopefully even find a solution to the presented issue.

Thank you very much in advance.

Cheers,
~Sergej

[0] https://lists.xen.org/archives/html/xen-devel/2017-08/msg00661.html

Sergej Proskurin (4):
  arm/monitor: Introduce monitoring of single-step events
  arm/domctl: Add XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_{ON|OFF}
  arm/traps: Allow trapping on single-step events
  vm_event: Move vm_event_toggle_singlestep to <xen/vm_event.h>

 xen/arch/arm/arm64/entry.S       |  2 ++
 xen/arch/arm/domctl.c            | 35 ++++++++++++++++++++++++++++
 xen/arch/arm/monitor.c           | 23 ++++++++++++++++++
 xen/arch/arm/traps.c             | 50 +++++++++++++++++++++++++++++++++++++++-
 xen/arch/arm/vm_event.c          | 11 +++++++++
 xen/include/asm-arm/domain.h     |  3 +++
 xen/include/asm-arm/monitor.h    |  5 +++-
 xen/include/asm-arm/perfc_defn.h |  1 +
 xen/include/asm-arm/processor.h  |  2 ++
 xen/include/asm-arm/vm_event.h   |  6 -----
 xen/include/asm-x86/vm_event.h   |  3 ---
 xen/include/xen/vm_event.h       |  3 +++
 12 files changed, 133 insertions(+), 11 deletions(-)

--
2.13.3


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel