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

[Julien Grall <julien.grall@xxxxxxx>]

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