Bug 233230 - [bhyve] [patch] usage() doesn't list -G debug server option
Summary: [bhyve] [patch] usage() doesn't list -G debug server option
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-virtualization (Nobody)
URL:
Keywords: bhyve, patch
Depends on:
Blocks:
 
Reported: 2018-11-14 21:16 UTC by Robert Wing
Modified: 2021-05-13 16:17 UTC (History)
5 users (show)

See Also:


Attachments
add -G, the debug server port option to bhyve usage message (476 bytes, patch)
2018-11-14 21:16 UTC, Robert Wing
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Wing freebsd_committer freebsd_triage 2018-11-14 21:16:33 UTC
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).
Comment 1 Ed Maste freebsd_committer freebsd_triage 2018-12-04 16:40:32 UTC
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.
Comment 2 Robert Wing freebsd_committer freebsd_triage 2018-12-06 20:34:33 UTC
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.
Comment 3 John Baldwin freebsd_committer freebsd_triage 2020-10-29 16:14:55 UTC
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.
Comment 4 Robert Wing freebsd_committer freebsd_triage 2020-11-02 18:59:22 UTC
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?
Comment 5 Peter Grehan freebsd_committer freebsd_triage 2020-11-03 00:20:10 UTC
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.
Comment 6 Mark Linimon freebsd_committer freebsd_triage 2021-05-13 13:10:19 UTC
^Triage: assign to mailing list.
Comment 7 John Baldwin freebsd_committer freebsd_triage 2021-05-13 16:17:30 UTC
This was added in commit b6a572d03f654236b929b91d376ad1a6dfaa2e9a.