Page MenuHomeFreeBSD

Initial debug server for bhyve.

Authored by jhb on Apr 9 2018, 8:43 PM.



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

rS FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

jhb created this revision.Apr 9 2018, 8:43 PM

happy but not able to test right now..

102 ↗(On Diff #41304)

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.

231 ↗(On Diff #41304)

not sure what Phabricator is telling us here..

emaste added inline comments.Apr 18 2018, 1:11 PM
102 ↗(On Diff #41304)

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

jhb added inline comments.Apr 18 2018, 5:05 PM
102 ↗(On Diff #41304)

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.

231 ↗(On Diff #41304)

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.

grehan accepted this revision.Apr 30 2018, 5:17 PM
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.