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] [-c [[cpus=]numcpus][,sockets=n][,cores=n][,threads=n]] [-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: help -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 -U: uuid -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.
Thanks for the insight John. Well..looking through the history, it appears bvmdebug was never intended to stick around anyway (as you already know) - so I guess the question is...is now the time to remove it? In r309295 (November 2016), avg notes that bvmdebug/bvmconsole *could* be removed, but that many existing deployments still depend on them. In addition to deferring to Peter, which mailing list (hackers, virtualization, current) should be used to get feedback on whether its time to deprecate bvmdebug and bvmconsole?
It is fine to deprecate these. As John mentioned, there are now much better ways to achieve the same functionality. A short email to the virtualization list should be enough to get confirmation this is ok.
^Triage: assign to mailing list.
This was added in commit b6a572d03f654236b929b91d376ad1a6dfaa2e9a.