Currently, lock of uart in bhyve is placed in frontend. There are some
problems about it:
1. If every frontend should has a lock, why not move it inside backend
as they all have same uart_softc.
2. If backend needs to modify the information of uart after initialize,
it will be impossible as backend cannot use lock. For example, if we
want implement a telnet support for uart in backend, It should wait
for connection when initialize. After some remote process connect it,
it needs to modify rfd and wfd in backend.
So I decide to move it to backend.
Reviewed by: corvink, jhb, markj
Differential Revision: https://reviews.freebsd.org/D44947
Just make "restore_file" a global variable so that it can be set by the
MD option handler.
Reviewed by: corvink
Reported by: bdrewery
Fixes: 981f9f7495 ("bhyve: Push option parsing down into bhyverun_machdep.c")
Differential Revision: https://reviews.freebsd.org/D44974
bhyve's man page is a very long block of text that has grown to
proportions that make it hard to read. In particular, the level of
nesting of various content means man can no longer render the text in a
user-friendly way.
To remedy this:
- move the -s argument documentation into a separate section and
reformat the various arguments so they are consistent
- add documentation on how to use the -o config.dump feature
- make the listing of various arguments more consistent
- consolidated duplicate listings of TPM backends
- add an example for the config.dump feature
- fix various formatting inconsistencies.
Reviewed by: emaste, imp, jrm, Pau Amma <pauamma@gundo.com>, rgrimes
Differential Revision: https://reviews.freebsd.org/D43940
- Mention the options that are amd64-only.
- Provide a minimal example for booting an arm64 guest.
Reviewed by: corvink
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D44738
It is a no-op on amd64 now and is not implemented on arm64, so let's
remove mention of it altogether so as to reduce confusion for arm64
users.
Reviewed by: corvink, jhb
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D44737
Unlike amd64's, this RTC is implemented entirely in userspace. This is
the same RTC as is provided by QEMU's virt machine.
Reviewed by: jhb
MFC after: 2 weeks
Obtained from: CheriBSD
This clock will also be used by the PL031 RTC (rather than defining
redundant per-device clocks).
Reviewed by: jhb
MFC after: 2 weeks
Obtained from: CheriBSD
This is supposed to combine with the memory range to make one contiguous
block, as is laid out in the FDT, so make this match what the OS is told
and thus actually configures.
Also drop the confusing leading zero from all three of these constants
that is making these 9 rather than 8 hex digits long (as one would
expect for a 32-bit address).
Reviewed by: jhb
MFC after: 2 weeks
Obtained from: CheriBSD
This allows us to remove various #ifdef hacks and enable building more
PCI devices.
Note that a hole is left in the interrupt mapping for the RTC rather
than having the two core devices straddle the PCIe interrupts. QEMU's
virt machine also takes this approach.
Reviewed by: jhb
MFC after: 2 weeks
Obtained from: CheriBSD
After a couple of attempts I think this is the cleanest approach despite
the expense of some code duplication. Quite a few of the single-letter
bhyve options are x86-specific.
I think that going forward we should strongly discourage the addition of
new options and instead configure guests using the more general
configuration file syntax.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D41753
A FreeBSD guest won't make use of this support and pci_lintr_* is not
implemented on arm64. Simply make pci_lintr_*() calls amd64-specific
for now.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D41741
- The extended config space and BAR ranges are listed in the FDT.
- Avoid referencing I/O ports in ACPI tables. Currently the arm64 port
does not support ACPI in any case.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D41739
Some required kernel functionality is not yet implemented.
For now this means that one cannot specify host PCI register values, but
that functionality is only used by amd64-specific device models for now.
Note that this limitation is rather artificial; it arises only because
pci_host_read_config() lives in pci_passthru.c.
Reviewed by: corvink, andrew, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D41738
This reduces the coupling between libvmmapi (which creates the highmem
segment) and bhyve, in preparation for the arm64 port.
No functional change intended.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40992
fdt.c provides some basic routines which let platform initialization
code build the FDT that gets passed into the guest. For now this is not
very generic; we declare info about CPUs, memory, a single UART
(specified by -o console), a PCIe controller (used for virtio devices),
an interrupt controller and the platform timer.
Co-authored-by: andrew
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40996
The arm64 port currently does not support ACPI, it instead builds up an
FDT which is exported to the guest. This mechanism will not be used on
amd64 but isn't really arm64-specific either, so provide an opt-in
mechanism to link libfdt.
No functional change intended.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40995
This will be use for arm64 guests, instead of the existing ns16550 UART
model.
Reviewed by: corvink, jhb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D40997
Currently bhyve implements a ns16550-compatible UART in uart_emul.c.
This file also contains generic code to manage RX FIFOs and to handle
reading from and writing to a TTY. bhyve instantiates UARTs to
implement COM devices (via pci_lpc.c) and PCI UART devices.
The arm64 port will bring with it a PL011 device model which is used as
the default console (i.e., no COM ports). To simplify its integration,
add a UART "backend" layer which lets UART device models allocate an RX
FIFO and interact with TTYs without duplicating code. In particular,
code in uart_backend.* is to be shared among device models, and the
namespace for uart_emul.* is changed to uart_ns16550_*.
This is based on andrew@'s work in
https://github.com/zxombie/freebsd/tree/bhyvearm64 but I've made a
number of changes, particularly with respect to naming and source code
organization.
No functional change intended.
Reviewed by: corvink, jhb
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D40993
Otherwise it's impossible to install from a read-only objdir.
Fixes: f81cdf24ba ("bhyve: Add support for XML register definitions")
Reported by: olivier
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
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
The current macro always builds a full mask for a named field, so use
the M suffix for mask.
Reviewed by: chuck, imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D43601
This is not a functional change, but just being consistent instead of
omitting a shift by 0.
Reviewed by: corvink, chuck, imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D43600
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
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
1. In basl_load() function, when allocation fails,
it returns an EFAULT instead of ENOMEM. An EFAULT
can mislead in some scenarios, whereas an ENOMEM
for an allocation function makes much more sense.
2. Call free() on addr, as it's not being used
anymore after the basl_table_append_bytes()
function.
Signed-off-by: rilysh <nightquick@proton.me>
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/1016
The USB3 spec mandates that the device-descriptor max packet size
be 512 bytes, which requires a field size of 9 since it is a
power-of-2.
Linux kernels recently started validating this field, resulting in
the table not being probed and the cursor not working in bhyve VNC.
Reviewed by: corvink
PR: 275760
MFC after: 1 week
The upper limits for height/width are already checked, this commit
enforces the lower limit as well.
The behavior is also changed such that, the framebuffer fails to
initialize if the provided values don't parse cleanly.
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D42692
After commit fb51ddb20d, suspending a vm fails with the error:
vm_snapshot_buf: buffer too small
Sponsored by: vStack
Reviewed by: markj, rew
Fixes: fb51ddb20d ("bhyve: increase fbuf display resolution limit")
Differential Revision: https://reviews.freebsd.org/D43218
In the function audio_init(), strlen() is being called two times,
first to get the length of dev_name and second to use in memcpy().
Creating a local variable and keeping the length avoids this
re-calculation.
Signed-off-by: rilysh <nightquick@proton.me>
Reviewed by: imp, zlei
Pull Request: https://github.com/freebsd/freebsd-src/pull/945
Apparently 19eaa01bea inserted -K description in the middle of -k.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential revision: https://reviews.freebsd.org/D43164
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
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
This enables a subset of the functionality provided by QEMU's user
networking implementation. In particular, it uses net/libslirp, the
same library as QEMU.
libslirp is permissively licensed but has some dependencies which make
it impractical to bring into the base system (glib in particular). I
thus opted to make bhyve dlopen the libslirp.so, which can be installed
via pkg. The library header is imported into bhyve.
The slirp backend takes a "hostfwd" which is identical to QEMU's
hostfwd. When configured, bhyve opens a host socket and listens for
connections, which get forwarded to the guest. For instance,
"hostfwd=tcp::1234-:22" allows one to ssh into the guest by ssh'ing to
port 1234 on the host, e.g., via 127.0.0.1. I didn't try to hook up
guestfwd support since I don't personally have a use-case for it yet,
and I think it won't interact nicely with the capsicum sandbox.
Reviewed by: jhb
Tested by: rew
MFC after: 1 month
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D42510
Currently the net_backend structure definition is private to
net_backends.c, so all of the backend definitions are there. While
adding a new backend to use libslirp, it was noted that this file is
somewhat cluttered. Move the netmap and netgraph backends to their own
files and clean up includes a bit. No functional change intended.
Reviewed by: corvink, jhb
MFC after: 3 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D42689
This enables connecting to the VNC server at a higher resolution.
Reviewed by: corvink, markj
Differential Revision: https://reviews.freebsd.org/D42620
