[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





On 05/09/17 09:57, Sergej Proskurin wrote:
Hi all,

Hello,

I am pretty sure I already said it before. It is quite annoying to have to search for the cover letter because you don't CC person involved in this. More that it contains useful details to understand the rest of this series...

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].

EL2 and EL1 single-step are 2 distinct use case. The former is for debugging the hypervisor, whilst the latter is for the guest. We should really differentiate both and focus on EL1 single-stepping.


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.

It makes sense, the monitor likely adds enough delay to get the timer raising an interrupt for the next deadline.


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.

One way to confirm if it is the cause is to disable the virtual CPU interface temporarily (see GICH_HCR.En on GICv2).

But what do you mean "as long as we are single-stepping the guest"? Is it only one instruction and could be multiple instructions?

If the latter, it means you delay the interrupt that may result in an infinite loop in the guest (imagine a code relying on interrupt...).

You may also want to single-step the interaction between a code and the interrupt.

Cheers,

--
Julien Grall

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.