freebsd-dev/usr.sbin/bhyve/Makefile

101 lines
1.5 KiB
Makefile
Raw Normal View History

#
# $FreeBSD$
#
.include <src.opts.mk>
CFLAGS+=-I${SRCTOP}/sys
.PATH: ${SRCTOP}/sys/cam/ctl
PROG= bhyve
2015-03-05 07:30:48 +00:00
PACKAGE= bhyve
MAN= bhyve.8
BHYVE_SYSDIR?=${SRCTOP}
SRCS= \
atkbdc.c \
acpi.c \
audio.c \
bhyvegc.c \
bhyverun.c \
block_if.c \
bootrom.c \
console.c \
consport.c \
ctl_util.c \
ctl_scsi_all.c \
dbgport.c \
fwctl.c \
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
2018-05-01 15:17:46 +00:00
gdb.c \
hda_codec.c \
inout.c \
ioapic.c \
mem.c \
mevent.c \
mptbl.c \
net_utils.c \
pci_ahci.c \
pci_e82545.c \
pci_emul.c \
pci_hda.c \
pci_fbuf.c \
pci_hostbridge.c \
2014-05-15 14:16:55 +00:00
pci_irq.c \
pci_lpc.c \
pci_nvme.c \
pci_passthru.c \
pci_virtio_block.c \
pci_virtio_console.c \
pci_virtio_net.c \
pci_virtio_rnd.c \
pci_virtio_scsi.c \
pci_uart.c \
pci_xhci.c \
pm.c \
post.c \
ps2kbd.c \
ps2mouse.c \
rfb.c \
rtc.c \
smbiostbl.c \
sockstream.c \
task_switch.c \
uart_emul.c \
usb_emul.c \
usb_mouse.c \
virtio.c \
vga.c \
xmsr.c \
spinup_ap.c \
iov.c
.PATH: ${BHYVE_SYSDIR}/sys/amd64/vmm
SRCS+= vmm_instruction_emul.c
LIBADD= vmmapi md pthread z util sbuf cam
.if ${MK_INET_SUPPORT} != "no"
CFLAGS+=-DINET
.endif
.if ${MK_INET6_SUPPORT} != "no"
CFLAGS+=-DINET6
.endif
.if ${MK_OPENSSL} == "no"
CFLAGS+=-DNO_OPENSSL
.else
LIBADD+= crypto
.endif
CFLAGS+= -I${BHYVE_SYSDIR}/sys/dev/e1000
CFLAGS+= -I${BHYVE_SYSDIR}/sys/dev/mii
CFLAGS+= -I${BHYVE_SYSDIR}/sys/dev/usb/controller
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
2018-05-01 15:17:46 +00:00
.ifdef GDB_LOG
CFLAGS+=-DGDB_LOG
.endif
WARNS?= 2
.include <bsd.prog.mk>