Page MenuHomeFreeBSD

Initial debug server for bhyve.
ClosedPublic

Authored by jhb on Apr 9 2018, 8:43 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Apr 10, 5:57 PM
Unknown Object (File)
Mar 1 2024, 8:28 AM
Unknown Object (File)
Jan 3 2024, 1:21 AM
Unknown Object (File)
Dec 20 2023, 5:18 AM
Unknown Object (File)
Dec 17 2023, 9:40 PM
Unknown Object (File)
Dec 12 2023, 8:35 AM
Unknown Object (File)
Nov 18 2023, 4:45 PM
Unknown Object (File)
Nov 16 2023, 8:33 PM

Details

Summary

This commit adds a new debug server to bhyve. Unlike the existing -g
option which provides an efficient connection to a debug server
running in the guest OS, this debug server permits inspection and
control of the guest from within the hypervisor itself without
requiring any cooperation from the guest. It is similar to the debug
server provided by qemu.

To avoid conflicting with the existing -g option, a new -G option has
been added that accepts a TCP port. An IPv4 socket is bound to this
port and listens for connections from debuggers. In addition, if the
port begins with the character 'w', the hypervisor will pause the
guest at the first instruction until a debugger attaches and
explicitly continues the guest. Note that only a single debugger can
attach to a guest at a time.

Virtual CPUs are exposed to the remote debugger as threads. General
purpose register values can be read for each virtual CPU. Other
registers cannot currently be read, and no register values can be
changed by the debugger.

The remote debugger can read guest memory but not write to guest
memory. To facilitate source-level debugging of the guest, memory
addresses from the debugger are treated as virtual addresses (rather
than physical addresses) and are resolved to a physical address using
the active virtual address translation of the current virtual CPU.
Memory reads should honor memory mapped I/O regions, though the debug
server does not attempt to honor any alignment or size constraints
when accessing MMIO.

The debug server provides limited support for controlling the guest.
The guest is suspended when a debugger is attached and resumes when a
debugger detaches. A debugger can suspend a guest by sending a Ctrl-C
request (e.g. via Ctrl-C in GDB). A debugger can also continue a
suspended guest while remaining attached. Breakpoints are not yet
supported. Single stepping is supported on Intel CPUs that support
MTRAP VM exits, but is not available on other systems.

While the current debug server has limited functionality, it should
at least be usable for basic debugging now. It is also a useful
checkpoint to serve as a base for adding additional features.

Test Plan
  • tested (with CAPSICUM) on Intel (though I've managed to expose a panic in CAPSICUM it seems when bhyve exits if the debugger is still attached).
  • avg@ tested an earlier version on AMD with CAPSICUM disabled

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 16082
Build 16044: arc lint + arc unit

Event Timeline

happy but not able to test right now..

usr.sbin/bhyve/gdb.c
102

very machine specific.. I think there are moves to run bhyve on non amd64 architectures..
in which case these shoudl be in a fiel with x86-64 (or something) in the name?
I'll go with whatever Peter says about this.

usr.sbin/bhyve/mem.c
231

not sure what Phabricator is telling us here..

usr.sbin/bhyve/gdb.c
102

In fact arm/arm64 changes are in progress and some are in review.

usr.sbin/bhyve/gdb.c
102

Yes, eventually this will need an MI/MD split, but the register stuff in particular is going to need more changes to support floating point, target descriptions so we can expose system registers, etc. Those changes will make it easier to do the split, but much of the code in this file as written is currently MI.

usr.sbin/bhyve/mem.c
231

If you move your mouse over the highlighted column it tells you. It is noting that the emulate_mem function start was moved from earlier in the file.

This revision is now accepted and ready to land.Apr 30 2018, 5:17 PM
This revision was automatically updated to reflect the committed changes.