Created attachment 199244 [details]
add -G, the debug server port option to bhyve usage message
The debug server option, -G, is documented in bhyve(8) but not shown in usage message:
Usage: bhyve [-abehuwxACHPSWY]
[-g <gdb port>] [-l <lpc>]
[-m mem] [-p vcpu:hostcpu] [-s <pci>] [-U uuid] <vm>
-a: local apic is in xAPIC mode (deprecated)
-A: create ACPI tables
-c: number of cpus and/or topology specification
-C: include guest memory in core file
-e: exit on unhandled I/O access
-g: gdb port
-H: vmexit from the guest on hlt
-l: LPC device configuration
-m: memory size in MB
-p: pin 'vcpu' to 'hostcpu'
-P: vmexit from the guest on pause
-s: <slot,driver,configinfo> PCI slot config
-S: guest memory cannot be swapped
-u: RTC keeps UTC time
-w: ignore unimplemented MSRs
-W: force virtio to use single-vector MSI
-x: local apic is in x2APIC mode
-Y: disable MPtable generation
Attached patch adds the -G option to bhyve usage message - patch is based off r340424 (HEAD).
Text should maybe be "Hypervisor debug server port" or similar - AIUI both -g and -G specify a debug server port, -g is passed through to the guest debug server while -G is the debug server running in bhyve itself.
Yea, I see what you're saying. Maybe the -g option should be more specific?
-g <remote gdb port>
starts a server that relays connections to a guest gdb stub
-G <local debug server port>
starts a server, intended for debugging purposes, for the bhyve instance.
If the -g option is documented as being a remote connection to the guest, perhaps the description 'debug server port' would suffice for the -G option. If not, I think adding 'local' or 'hypervisor' to the -G option would get the point across.
I think it might be useful to constrain the description of -g a bit. It only works for guests that support the 'bvmdebug' driver (which currently only exists for FreeBSD AFAIK), and similar to 'bmconsole' mostly existed as a simple device model before bhyve supported UARTs. A more portable approach to connect to a gdb stub in a guest OS now is to use a UART to do so (e.g. I wire up /dev/nmdm<vm>2B to com2 for my guests so that gdb can connect to /dev/nmdm<vm>2A to connect to a gdb stub on com2 in the guest which potentially works with multiple OSes). -G is more like qemu's -g.
I'd be tempted to deprecate bvmconsole and bvmdebug, but I'd defer to Peter on that. I realize we'd need to document -G better regardless, but if we want to move forward with deprecating bvmdebug it might affect the language we use to describe -g vs -G.