#
5d62025d |
|
07-May-2024 |
Mark Johnston <markj@FreeBSD.org> |
bhyve: Do not define GDB_LOG This had been added for debugging and shouldn't have been committed. Fixes: f81cdf24ba54 ("bhyve: Add support for XML register definitions") MFC after: 3 days
|
#
f81cdf24 |
|
20-Feb-2024 |
Mark Johnston <markj@FreeBSD.org> |
bhyve: Add support for XML register definitions This is useful for exposing additional registers to debuggers. For instance, control registers are now available on amd64 when using gdb to debug a guest. The stub indicates support by including the string "qXfer:features:read+" in its feature list. The debugger queries for target descriptions by sending the query "qXfer:features:read:" followed by a file path. The XML definitions are copied from QEMU and installed to /usr/share/bhyve/gdb. Note that we currently don't handle the SIMD registers at all, since that's of somewhat limited utility (for me at least) and since that requires new ioctls to fetch the register values. Reviewed by: jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D43666
|
#
e6516294 |
|
07-Feb-2024 |
Mark Johnston <markj@FreeBSD.org> |
bhyve: Add support for the 'p' query This lets gdb query individual registers. It's easy to implement and is used by gdb when attaching to a CHERI target, so let's support it. Sponsored by: Innovate UK Reviewed by: corvink, jhb MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D43664
|
#
5f086566 |
|
23-Jan-2024 |
Mark Johnston <markj@FreeBSD.org> |
bhyve: Prepare to add arm64 support to the gdb stub In particular: - Stop assuming that the breakpoint size is one byte. - Avoid referencing the "rip" field in machine-independent code, use a helper. No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D43483
|
#
5e728af4 |
|
23-Jan-2024 |
Mark Johnston <markj@FreeBSD.org> |
bhyve: Simplify register definitions a bit It's awkward to have separate tables for information which is logically connected. Merge the gdb_regset[] and gdb_regsize[] arrays and update gdb_read_regs() to cope with the result. This makes the addition of arm64 support a bit cleaner. No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D43481
|
#
cfa2c78a |
|
23-Jan-2024 |
Mark Johnston <markj@FreeBSD.org> |
bhyve: Avoid underflows when handling remote commands Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D43480
|
#
ca96a942 |
|
12-Dec-2023 |
Bojan Novković <bojan.novkovic@fer.hr> |
bhyve: refactor gdbstub to enable single-stepping on AMD CPUs This patch refactors the existing Intel-specific single-stepping mechanism in bhyve's GDB stub to work with both AMD and Intel CPUs. Reviewed by: jhb Sponsored by: Google, Inc. (GSoC 2022) Differential Revision: https://reviews.freebsd.org/D42298
|
#
4d65a7c6 |
|
24-Nov-2023 |
Warner Losh <imp@FreeBSD.org> |
usr.sbin: Automated cleanup of cdefs and other formatting Apply the following automated changes to try to eliminate no-longer-needed sys/cdefs.h includes as well as now-empty blank lines in a row. Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/ Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/ Remove /\n+#if.*\n#endif.*\n+/ Remove /^#if.*\n#endif.*\n/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/ Sponsored by: Netflix
|
#
4e288572 |
|
10-Nov-2023 |
Mark Johnston <markj@FreeBSD.org> |
bhyve: Fix the GDB_LOG build MFC after: 1 week Fixes: 7d9ef309bd09 ("libvmmapi: Add a struct vcpu and use it in most APIs.")
|
#
b0936440 |
|
16-Oct-2023 |
John Baldwin <jhb@FreeBSD.org> |
bhyve: Replace many fprintf(stderr, ...) calls with EPRINTLN EPRINTLN handles newlines appropriately when stdout/stderr have been reused as the backend for a serial port. For bhyverun.c itself, the rule this attempts to follow is to use regular fprintf/perror/warn/err prior to init_pci() (which is when serial ports are configured) and to switch to EPRINTLN afterwards. Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D42182
|
#
1d386b48 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: one-line .c pattern Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
4d846d26 |
|
10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
|
#
fefac543 |
|
09-May-2023 |
Bojan Novković <bojan.novkovic@fer.hr> |
bhyve: fix vCPU single-stepping on VMX This patch fixes virtual machine single stepping on VMX hosts. Currently, when using bhyve's gdb stub, each attempt at single-stepping a vCPU lands in a timer interrupt. The current single-stepping mechanism uses the Monitor Trap Flag feature to cause VMEXIT after a single instruction is executed. Unfortunately, the SDM states that MTF causes VMEXITs for the next instruction that gets executed, which is often not what the person using the debugger expects. [1] This patch adds a new VM capability that masks interrupts on a vCPU by blocking interrupt injection and modifies the gdb stub to use the newly added capability while single-stepping a vCPU. [1] Intel SDM 26.5.2 Vol. 3C Reviewed by: corvink, jbh MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D39949
|
#
7d9ef309 |
|
24-Mar-2023 |
John Baldwin <jhb@FreeBSD.org> |
libvmmapi: Add a struct vcpu and use it in most APIs. This replaces the 'struct vm, int vcpuid' tuple passed to most API calls and is similar to the changes recently made in vmm(4) in the kernel. struct vcpu is an opaque type managed by libvmmapi. For now it stores a pointer to the VM context and an integer id. As an immediate effect this removes the divergence between the kernel and userland for the instruction emulation code introduced by the recent vmm(4) changes. Since this is a major change to the vmmapi API, bump VMMAPI_VERSION to 0x200 (2.0) and the shared library major version. While here (and since the major version is bumped), remove unused vcpu argument from vm_setup_pptdev_msi*(). Add new functions vm_suspend_all_cpus() and vm_resume_all_cpus() for use by the debug server. The underyling ioctl (which uses a vcpuid of -1) remains unchanged, but the userlevel API now uses separate functions for global CPU suspend/resume. Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D38124
|
#
ed721684 |
|
23-Oct-2022 |
Mark Johnston <markj@FreeBSD.org> |
bhyve: Address some signed/unsigned comparison warnings MFC after: 1 week
|
#
98d920d9 |
|
08-Oct-2022 |
Mark Johnston <markj@FreeBSD.org> |
bhyve: Annotate unused function parameters MFC after: 1 week
|
#
37045dfa |
|
16-Aug-2022 |
Mark Johnston <markj@FreeBSD.org> |
bhyve: Mark variables and functions as static where appropriate Mark them const as well when it makes sense to do so. No functional change intended. MFC after: 1 week Sponsored by: The FreeBSD Foundation
|
#
927aa5fe |
|
07-Feb-2022 |
Mark Johnston <markj@FreeBSD.org> |
bhyve: Fix getaddrinfo() error handling - Use errx() since errno will not be set. - Print the message returned by gai_strerror(). MFC after: 1 week Sponsored by: The FreeBSD Foundation
|
#
3a92927b |
|
19-Aug-2021 |
Mariusz Zaborski <oshogbo@FreeBSD.org> |
bhyve: change a default address from ANY to localhost Discussed with: grehan, jhb
|
#
2cdff991 |
|
19-Aug-2021 |
Mariusz Zaborski <oshogbo@FreeBSD.org> |
byhve: add option to specify IP address for gdb Allow user to specify the IP address available for gdb debugger. Reviewed by: jhb, grehan, rgrimes, bcr (man pages) Differential Revision: https://reviews.freebsd.org/D29607
|
#
02e7a651 |
|
02-May-2021 |
Mark Johnston <markj@FreeBSD.org> |
bhyve: Set SO_REUSEADDR on the gdb stub socket Reviewed by: jhb MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D30037
|
#
eacc27af |
|
12-Apr-2021 |
John Baldwin <jhb@FreeBSD.org> |
bhyve: Move the gdb_active check to gdb_cpu_suspend(). The check needs to be in the public routine (gdb_cpu_suspend()), not in the internal routine called from various places (_gdb_cpu_suspend()). All the other callers of _gdb_cpu_suspend() already check gdb_active, and this breaks the use of snapshots when the debug server is not enabled since gdb_cpu_suspend() tries to lock an uninitialized mutex. Reported by: Darius Mihai, Elena Mihailescu Reviewed by: elenamihailescu22_gmail.com Fixes: 621b5090487de9fed1b503769702a9a2a27cc7bb Differential Revision: https://reviews.freebsd.org/D29538
|
#
621b5090 |
|
26-Jun-2019 |
John Baldwin <jhb@FreeBSD.org> |
Refactor configuration management in bhyve. Replace the existing ad-hoc configuration via various global variables with a small database of key-value pairs. The database supports heirarchical keys using a MIB-like syntax to name the path to a given key. Values are always stored as strings. The API used to manage configuation values does include wrappers to handling boolean values. Other values use non-string types require parsing by consumers. The configuration values are stored in a tree using nvlists. Leaf nodes hold string values. Configuration values are permitted to reference other configuration values using '%(name)'. This permits constructing template configurations. All existing command line arguments now set configuration values. For devices, the "-s" option parses its option argument to generate a list of key-value pairs for the given device. A new '-o' command line option permits setting an individual configuration variable. The key name is always given as a full path of dot-separated components. A new '-k' command line option parses a simple configuration file. This configuration file holds a flat list of 'key=value' lines where the 'key' is the full path of a configuration variable. Lines starting with a '#' are comments. In general, bhyve starts by parsing command line options in sequence and applying those settings to configuration values. Once this is complete, bhyve then begins initializing its state based on the configuration values. This means that subsequent configuration options or files may override or supplement previously given settings. A special 'config.dump' configuration value can be set to true to help debug configuration issues. When this value is set, bhyve will print out the configuration variables as a flat list of 'key=value' lines. Most command line argments map to a single configuration variable, e.g. '-w' sets the 'x86.strictmsr' value to false. A few command line arguments have less obvious effects: - Multiple '-p' options append their values (as a comma-seperated list) to "vcpu.N.cpuset" values (where N is a decimal vcpu number). - For '-s' options, a pci.<bus>.<slot>.<function> node is created. The first argument to '-s' (the device type) is used as the value of a "device" variable. Additional comma-separated arguments are then parsed into 'key=value' pairs and used to set additional variables under the device node. A PCI device emulation driver can provide its own hook to override the parsing of the additonal '-s' arguments after the device type. After the configuration phase as completed, the init_pci hook then walks the "pci.<bus>.<slot>.<func>" nodes. It uses the "device" value to find the device model to use. The device model's init routine is passed a reference to its nvlist node in the configuration tree which it can query for specific variables. The result is that a lot of the string parsing is removed from the device models and centralized. In addition, adding a new variable just requires teaching the model to look for the new variable. - For '-l' options, a similar model is used where the string is parsed into values that are later read during initialization. One key note here is that the serial ports use the commonly used lowercase names from existing documentation and examples (e.g. "lpc.com1") instead of the uppercase names previously used internally in bhyve. Reviewed by: grehan MFC after: 3 months Differential Revision: https://reviews.freebsd.org/D26035
|
#
f3eb12e4 |
|
23-Aug-2020 |
Konstantin Belousov <kib@FreeBSD.org> |
Add bhyve support for LA57 guest mode. Noted and reviewed by: grehan Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D25273
|
#
cbd03a9d |
|
13-Dec-2019 |
John Baldwin <jhb@FreeBSD.org> |
Support software breakpoints in the debug server on Intel CPUs. - Allow the userland hypervisor to intercept breakpoint exceptions (BP#) in the guest. A new capability (VM_CAP_BPT_EXIT) is used to enable this feature. These exceptions are reported to userland via a new VM_EXITCODE_BPT that includes the length of the original breakpoint instruction. If userland wishes to pass the exception through to the guest, it must be explicitly re-injected via vm_inject_exception(). - Export VMCS_ENTRY_INST_LENGTH as a VM_REG_GUEST_ENTRY_INST_LENGTH pseudo-register. Injecting a BP# on Intel requires setting this to the length of the breakpoint instruction. AMD SVM currently ignores writes to this register (but reports success) and fails to read it. - Rework the per-vCPU state tracked by the debug server. Rather than a single 'stepping_vcpu' global, add a structure for each vCPU that tracks state about that vCPU ('stepping', 'stepped', and 'hit_swbreak'). A global 'stopped_vcpu' tracks which vCPU is currently reporting an event. Event handlers for MTRAP and breakpoint exits loop until the associated event is reported to the debugger. Breakpoint events are discarded if the breakpoint is not present when a vCPU resumes in the breakpoint handler to retry submitting the breakpoint event. - Maintain a linked-list of active breakpoints in response to the GDB 'Z0' and 'z0' packets. Reviewed by: markj (earlier version) MFC after: 2 months Differential Revision: https://reviews.freebsd.org/D20309
|
#
4db23c74 |
|
05-Jun-2019 |
John Baldwin <jhb@FreeBSD.org> |
Use parse_integer to avoid sign extension. Coverity warned about gdb_write_mem sign extending the result of parse_byte shifted left by 24 bits when generating a 32-bit memory write value for MMIO. Simplify the code by using parse_integer instead of unrolled parse_byte calls. CID: 1401600 Reviewed by: cem MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D20508
|
#
07e007e1 |
|
24-May-2019 |
John Baldwin <jhb@FreeBSD.org> |
Add initial support for 'qSupported' to the debug server. This doesn't recognize any features yet, but does parse the features string. It advertises an arbitrary packet size of 4k. Reviewed by: markj, Scott Phillips <d.scott.phillips@intel.com> MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D20308
|
#
1b52cd45 |
|
23-May-2019 |
John Baldwin <jhb@FreeBSD.org> |
Add support for writing to guest memory in the debug server. - Add a write_mem counterpart to read_mem to handle writes to MMIO. - Add support for the GDB 'M' packet to write bytes to the guest's memory. For MMIO writes, attempt to batch writes up into words. This is imprecise, but if you write a single 2 or 4-byte aligned word, it should be treated as a single MMIO write operation. - While here, tidy up the parsing of the 'm' command used for reading memory to match 'M'. Reviewed by: markj, Scott Phillips <d.scott.phillips@intel.com> MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D20307
|
#
2e43efd0 |
|
06-Mar-2019 |
John Baldwin <jhb@FreeBSD.org> |
Drop "All rights reserved" from my copyright statements. Reviewed by: rgrimes MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D19485
|
#
abfa3c39 |
|
15-Jan-2019 |
Marcelo Araujo <araujo@FreeBSD.org> |
Use capsicum_helpers(3) that allow us to simplify the code and its functions will return success when the kernel is built without support of the capability mode. It is important to note, that I'm taking a more conservative approach with these changes and it will be done in small steps. Reviewed by: jhb MFC after: 6 weeks Differential Revision: https://reviews.freebsd.org/D18744
|
#
cd377eb3 |
|
01-May-2018 |
John Baldwin <jhb@FreeBSD.org> |
Initial debug server for bhyve. 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. Reviewed by: grehan Differential Revision: https://reviews.freebsd.org/D15022
|