[Qemu-devel] [RFC PATCH 0/1] single step for KVM HV

Fabiano Rosas posted 1 patch 5 years, 5 months ago
Test asan passed
Test checkpatch passed
Test docker-quick@centos7 passed
Test docker-mingw@fedora passed
Test docker-clang@ubuntu passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20181119213739.773-1-farosas@linux.ibm.com
accel/kvm/kvm-all.c  | 10 +++++++
exec.c               |  1 +
include/sysemu/kvm.h |  4 +++
target/arm/kvm.c     |  4 +++
target/i386/kvm.c    |  4 +++
target/ppc/kvm.c     | 65 +++++++++++++++++++++++++++++++++++++++++++-
target/s390x/kvm.c   |  4 +++
7 files changed, 91 insertions(+), 1 deletion(-)
[Qemu-devel] [RFC PATCH 0/1] single step for KVM HV
Posted by Fabiano Rosas 5 years, 5 months ago
Single stepping via GDB/gdbstub is currently not working with KVM
HV. When asking for a single step (stepi), KVM simply ignores the
request and execution continues.

This has the direct effect of breaking GDB's 'step', 'stepi', 'next',
'nexti' commands. The 'continue' command is also affected since
continuing right after a breakpoint requires that GDB first perform a
single step so that the breakpoint can be re-inserted before
continuing - in this case the breakpoint is not re-inserted and it
won't hit again.

The issue here is that single stepping in POWER makes use of an
interrupt (Trace Interrupt [1]) that does not reach the hypervisor, so
while the single step would happen if properly triggered, it would not
cause an exit to KVM so there would be no way of handing control back
to GDB. Aside from that, the guest kernel is not prepared to deal with
such an interrupt in kernel mode (when not using KGDB, or some other
debugging facility) and it causes an Oops.

This series implements a "software single step" approach that makes
use of: i) the Trace Interrupt to perform the step inside the guest
and ii) a breakpoint at the Trace Interrupt handler address to cause a
vm exit (Emulation Assist) so that we can return control to QEMU.

With (i), we basically get the single step for free, without having to
discover what are the possible targets of instructions that divert
execution.

With (ii), we hide the single step from the guest and keep all of the
step logic in QEMU.

This was so far tested with single and multiple vcpus and with GDB
scheduler locking on and off [2].

I have not fully explored yet the potential issues when using
debuggers simultaneously inside and outside the guest, however I was
able to single step the ptrace code while single stepping a userspace
program inside the guest with GDB.

I'm looking for feedback on the general approach before I develop this
further.

1- PowerISA Section 6.5.15 - Trace Interrupt
2- https://sourceware.org/gdb/onlinedocs/gdb/All_002dStop-Mode.html


Fabiano Rosas (1):
  target/ppc: support single stepping with KVM HV

 accel/kvm/kvm-all.c  | 10 +++++++
 exec.c               |  1 +
 include/sysemu/kvm.h |  4 +++
 target/arm/kvm.c     |  4 +++
 target/i386/kvm.c    |  4 +++
 target/ppc/kvm.c     | 65 +++++++++++++++++++++++++++++++++++++++++++-
 target/s390x/kvm.c   |  4 +++
 7 files changed, 91 insertions(+), 1 deletion(-)

--
2.17.1