John Baldwin [Thu, 2 May 2024 23:33:50 +0000 (16:33 -0700)]
ctl_backend_ramdisk: Add support for NVMe
One known caveat is that the support for WRITE_UNCORRECTABLE is not
quite correct as reads from LBAs after a WRITE_UNCORRECTABLE will
return zeroes rather than an error. Fixing this would likely require
special handling for PG_ANCHOR for NVMe requests (or adding a new
PG_UNCORRECTABLE).
John Baldwin [Thu, 2 May 2024 23:32:41 +0000 (16:32 -0700)]
ctl: Add helper routines to populate NVMe namespace data IDs for a LUN
These will be used by the backends to populate the unique ID fields
like EUI64 in the NVMe namespace data (CNS == 0) and namespace
identification descriptor list (CNS == 3).
John Baldwin [Thu, 2 May 2024 23:32:09 +0000 (16:32 -0700)]
ctl: Support for NVMe commands
- Add support for queueing and executing NVMe admin and NVM commands
via ctl_run and ctl_queue. This requires fixing a few places that
were SCSI-specific to add NVME logic.
- NVMe has much simpler command ordering requirements than SCSI. In
particular, the HBA is not required to enforce any specific ordering
for requests with overlapping LBAs. The host is required to manage
that ordering. However, fused commands (currently only COMPARE and
WRITE NVM commands can be fused) are required to be executed
atomically.
To support fused commands, make the second half of a fused command
block on the first half, and have commands submitted after a fused
command pair block on the second half.
- Add handlers and command tables for admin and NVM commands that
operate on individual namespaces and will be passed down from an
NVMe over Fabrics controller to a CTL LUN.
John Baldwin [Thu, 2 May 2024 23:31:59 +0000 (16:31 -0700)]
ctl: Add assertions in SCSI-only paths
Assert that only SCSI I/O requests are passed in various places
that assume a SCSI I/O request (that is, places that access fields
in io->scsiio directly).
John Baldwin [Thu, 2 May 2024 23:31:44 +0000 (16:31 -0700)]
ctl: Update some core data paths to be protocol agnostic
- Add wrapper routines for invoking the be_move_done and io_continue
callbacks in SCSI and NVMe I/O requests.
- Use wrapper routines for access to shared fields between SCSI and
NVMe I/O requests.
- ctl_config_write_done is not fully updated since it resubmits SCSI
commands via ctl_scsiio. This will be completed in a subsequent
commit when ctl_nvmeio is added.
John Baldwin [Thu, 2 May 2024 23:30:20 +0000 (16:30 -0700)]
ctl: Avoid an upcast for calling ctl_scsi_path_string
Change the first argument of ctl_scsi_path_string to be the embedded
header structure instead of the union. Currently union ctl_io and
struct ctl_scsiio have the same alignment, but this changes on i386 if
a new union member is added that contains a uint64_t member (such as
an embedded struct nvme_command for NVMeoF). In that case, union
ctl_io requires stronger alignment, so the upcast from struct
ctl_scsiio to union ctl_io in ctl_scsi_sense_sbuf raises an increasing
alignment warning on i386.
Avoid the warning by passing struct ctl_io_hdr as the first argument
to ctl_scsi_path_string instead.
John Baldwin [Thu, 2 May 2024 23:30:10 +0000 (16:30 -0700)]
nvmecontrol: New commands to support Fabrics hosts
- discover: Connects to a remote Discovery controller, fetches its
Discovery Log Page, and enumerates the remote controllers described
in the log page.
The -v option can be used to display the Identify Controller data
structure for the Discovery controller. This is only really useful
for debugging.
- connect: Connects to a remote I/O controller and establishes an
association of an admin queue and a single I/O queue. The
association is handed off to the in-kernel host to create a new
nvmeX device.
- connect-all: Connects to a Discovery controller and attempts to
create an association with each I/O controller enumerated in the
Discovery controller's Discovery Log Page.
- reconnect: Establishes a new association with a remote I/O
controller for an existing nvmeX device. This can be used to
restore access to a remote I/O controller after the loss of a prior
association due to a transport error, controller reboot, etc.
- disconnect: Deletes one or more nvmeX devices after detaching its
namespaces and terminating any active associations. The devices to
delete can be identified by either a nvmeX device name or the NQN of
the remote controller.
- disconnect-all: Deletes all active associations with remote
controllers.
John Baldwin [Thu, 2 May 2024 23:29:37 +0000 (16:29 -0700)]
nvmf: The in-kernel NVMe over Fabrics host
This is the client (initiator in SCSI terms) for NVMe over Fabrics.
Userland is responsible for creating a set of queue pairs and then
handing them off via an ioctl to this driver, e.g. via the 'connect'
command from nvmecontrol(8). An nvmeX new-bus device is created
at the top-level to represent the remote controller similar to PCI
nvmeX devices for PCI-express controllers.
As with nvme(4), namespace devices named /dev/nvmeXnsY are created and
pass through commands can be submitted to either the namespace devices
or the controller device. For example, 'nvmecontrol identify nvmeX'
works for a remote Fabrics controller the same as for a PCI-express
controller.
nvmf exports remote namespaces via nda(4) devices using the new NVMF
CAM transport. nvmf does not support nvd(4), only nda(4).
John Baldwin [Thu, 2 May 2024 23:28:47 +0000 (16:28 -0700)]
nvmf_tcp: Add a TCP transport for NVMe over Fabrics
Structurally this is very similar to the TCP transport for iSCSI
(icl_soft.c). One key difference is that NVMeoF transports use a more
abstract interface working with NVMe commands rather than transport
PDUs. Thus, the data transfer for a given command is managed entirely
in the transport backend.
Similar to icl_soft.c, separate kthreads are used to handle transmit
and receive for each queue pair. On the transmit side, when a capsule
is transmitted by an upper layer, it is placed on a queue for
processing by the transmit thread. The transmit thread converts
command response capsules into suitable TCP PDUs where each PDU is
described by an mbuf chain that is then queued to the backing socket's
send buffer. Command capsules can embed data along with the NVMe
command.
On the receive side, a socket upcall notifies the receive kthread when
more data arrives. Once enough data has arrived for a PDU, the PDU is
handled synchronously in the kthread. PDUs such as R2T or data
related PDUs are handled internally, with callbacks invoked if a data
transfer encounters an error, or once the data transfer has completed.
Received capsule PDUs invoke the upper layer's capsule_received
callback.
struct nvmf_tcp_command_buffer manages a TCP command buffer for data
transfers that do not use in-capsule-data as described in the NVMeoF
spec. Data related PDUs such as R2T, C2H, and H2C are associated with
a command buffer except in the case of the send_controller_data
transport method which simply constructs one or more C2H PDUs from the
caller's mbuf chain.
John Baldwin [Thu, 2 May 2024 23:28:32 +0000 (16:28 -0700)]
nvmf: Add infrastructure kernel module for NVMe over Fabrics
nvmf_transport.ko provides routines for managing NVMeoF queue pairs
and capsules. It provides a glue layer between transports (such as
TCP or RDMA) and an NVMeoF host (initiator) and controller (target).
Unlike the synchronous API exposed to the host and controller by
libnvmf, the kernel's transport layer uses an asynchronous API built
on callbacks. Upper layers provide callbacks on queue pairs that are
invoked for transport errors (error_cb) or anytime a capsule is
received (receive_cb).
Data transfers for a command are usually associated with a callback
that is invoked once a transfer has finished either due to an error
or successful completion.
For an upper layer that is a host, command capsules are allocated and
populated with an NVMe SQE by calling nvmf_allocate_command. A data
buffer (described by a struct memdesc) can be associated with a
command capsule before it is transmitted via nvmf_capsule_append_data.
This function accepts a direction (send vs receive) as well as the
data transfer callback. The host then transmits the command via
nvmf_transmit_capsule. The host must ensure that the data buffer
described by the 'struct memdesc' remains valid until the data
transfer callback is called. The queue pair's receive_cb callback
should match received response capsules up with previously transmitted
commands.
For the controller, incoming commands are received via the queue
pair's receive_cb callback. nvmf_receive_controller_data is used to
retrieve any data from a command (e.g. the data for a WRITE command).
It can be called multiple times to split the data transfer into
smaller sizes. This function accepts an I/O completion callback that
is invoked once the data transfer has completed.
nvmf_send_controller_data is used to send data to a remote host in
response to a command. In this case a callback function is not used
but the status is returned synchronously. Finally, the controller can
allocate a response capsule via nvmf_allocate_response populated with
a supplied CQE and send the response via nvmf_transmit_capsule.
John Baldwin [Thu, 2 May 2024 23:28:16 +0000 (16:28 -0700)]
libnvmf: Add internal library to support NVMe over Fabrics
libnvmf provides APIs for transmitting and receiving Command and
Response capsules along with data associated with NVMe commands.
Capsules are represented by 'struct nvmf_capsule' objects.
Capsules are transmitted and received on queue pairs represented by
'struct nvmf_qpair' objects.
Queue pairs belong to an association represented by a 'struct
nvmf_association' object.
libnvmf provides additional helper APIs to assist with constructing
command capsules for a host, response capsules for a controller,
connecting queue pairs to a remote controller and optionally
offloading connected queues to an in-kernel host, accepting queue pair
connections from remote hosts and optionally offloading connected
queues to an in-kernel controller, constructing controller data
structures for local controllers, etc.
libnvmf also includes an internal transport abstraction as well as an
implementation of a userspace TCP transport.
libnvmf is primarily intended for ease of use and low-traffic use cases
such as establishing connections that are handed off to the kernel.
As such, it uses a simple API built on blocking I/O.
For a host, a consumer first populates an 'struct
nvmf_association_params' with a set of parameters shared by all queue
pairs for a single association such as whether or not to use SQ flow
control and header and data digests and creates a 'struct
nvmf_association' object. The consumer is responsible for
establishing a TCP socket for each queue pair. This socket is
included in the 'struct nvmf_qpair_params' passed to 'nvmf_connect' to
complete transport-specific negotiation, send a Fabrics Connect
command, and wait for the Connect reply. Upon success, a new 'struct
nvmf_qpair' object is returned. This queue pair can then be used to
send and receive capsules. A command capsule is allocated, populated
with an SQE and optional data buffer, and transmitted via
nvmf_host_transmit_command. The consumer can then wait for a reply
via nvmf_host_wait_for_response. The library also provides some
wrapper functions such as nvmf_read_property and nvmf_write_property
which send a command and wait for a response synchronously.
For a controller, a consumer uses a single association for a set of
incoming connections. A consumer can choose to use multiple
associations (e.g. a separate association for connections to a
discovery controller listening on a different port than I/O
controllers). The consumer is responsible for accepting TCP sockets
directly, but once a socket has been accepted it is passed to
nvmf_accept to perform transport-specific negotiation and wait for the
Connect command. Similar to nvmf_connect, nvmf_accept returns a newly
construct nvmf_qpair. However, in contrast to nvmf_connect,
nvmf_accept does not complete the Fabrics negotiation. The consumer
must explicitly send a response capsule before waiting for additional
command capsules to arrive. In particular, in the kernel offload
case, the Connect command and data are provided to the kernel
controller and the Connect response capsule is sent by the kernel once
it is ready to handle the new queue pair.
For userspace controller command handling, the consumer uses
nvmf_controller_receive_capsule to wait for a command capsule.
nvmf_receive_controller_data is used to retrieve any data from a
command (e.g. the data for a WRITE command). It can be called
multiple times to split the data transfer into smaller sizes.
nvmf_send_controller_data is used to send data to a remote host in
response to a command. It also sends a response capsule indicating
success, or an error if an internal error occurs. nvmf_send_response
is used to send a response without associated data. There are also
several convenience wrappers such as nvmf_send_success and
nvmf_send_generic_error.
John Baldwin [Thu, 2 May 2024 23:27:53 +0000 (16:27 -0700)]
nvmft: Add NVMeoF controller routines shared between kernel and userland
This includes functions to validate NVMe Qualified Names, compute an
initial value of the CAP property, validate changes to the CC
property, and populate the Identify Controller data structure for an
I/O controller.
John Baldwin [Thu, 2 May 2024 23:26:16 +0000 (16:26 -0700)]
nvmf_proto.h: NVMe over Fabrics protocol definitions
This is a copy of spdk/include/spdk/nvmf_spec.h as of commit 470e851852bb948334a272c9f8de495020fa082f from Intel's SPDK.
Subsequent commits will modify it to be suitable header for the
kernel, but importing the stock file first makes it easier to see
how the resulting header is derived from the original.
Warner Losh [Thu, 2 May 2024 21:58:55 +0000 (15:58 -0600)]
cam/iosched: Document latency buckets correctly.
Document how latency buckets are actually computed: They are a doubling
from 20us to 10.485s by default, but based at
kern.cam.iosched.bucket_base_us and increase with a ratio of
kern.cam.iosched.bucket_ration / 100 from one to the next.
Warner Losh [Sun, 28 Apr 2024 17:01:24 +0000 (11:01 -0600)]
nvmecontrol: Allow optional /dev/ for device names
nvmecontrol operates on devices. Allow a user to specify the /dev/ if
they want. Any device that starts with / will be treated as if it was a
full path for maximum flexbility.
Mark Johnston [Wed, 1 May 2024 11:57:56 +0000 (07:57 -0400)]
sysctl: Make sysctl_ctx_free() a bit safer
Clear the list before returning so that sysctl_ctx_free() can be called
more than once on the same list without side effects. This simplifies
error handling in drivers; previously, drivers would have to be careful
to call sysctl_ctx_free() at most once to avoid a use-after-free.
While here, use TAILQ_FOREACH_SAFE in the loop which unregisters OIDs.
Mike Karels [Thu, 2 May 2024 15:24:37 +0000 (10:24 -0500)]
in6.h: expose s6_addr* definitions to user level
The only element of of in6_addr that is specified in RFC 3493 or
in POSIX.1-2017 is s6_addr, implemented via a #define to a union
member. However, FreeBSD and other BSD systems have additional
definitions for the other union members, s6_addr{8,16,32} which
are defined for the kernel and loader. Some Linux applications
also use them, and they seem to be allowed by the RFC and POSIX.
Remove the current ifdefs, exposing the additional fields to user
level, and replace with #if __BSD_VISIBLE. Add an explanatory
comment expanding on the previous "nonstandard" comment.
In the error path during allocating an in_pcb, the credentials
associated with the new struct get their reference count
increased early on, but not decremented when the allocation
fails.
Reported by: cmiller_netapp.com
MFC after: 3 days
Reviewed by: jhb, tuexen
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D45033
guestrpc module to handle VMware backdoor port GuestRPC functionality
Convert existing FreeBSD vmware_hvcall function to take a channel
and parameter arguments.
Added vmware_guestrpc_cmd() to send GuestRPC commands to the VMware
hypervisor. The sbuf argument is used for both the command to send
and to store the data to return to the caller.
The following KPIs can be used to get and set FreeBSD-specific guest
information in key/value pairs:
* vmware_guestrpc_set_guestinfo
- set a value into the guestinfo.fbsd.<keyword> key
* vmware_guestrpc_get_guestinfo
- get the value stored in the guestinfo.fbsd.<keyword> key
Colin Percival [Wed, 1 May 2024 17:56:51 +0000 (10:56 -0700)]
release: Stage non-UFS images in vm-images-stage
When the VM image building code was updated to support building
non-UFS images, the vm-images-stage target was not updated to
install those newly built images to the FTP site. As a result, we
have been sending weekly snapshot announcements since August claiming
that ZFS VM images are available when they are not in fact present
anywhere publicly accessible.
Fixes: 32ae9a6b3937 "release: Build UFS and ZFS VM images"
Reported by: Michael Dexter
MFC after: 5 days
SHENG-YI HONG [Wed, 1 May 2024 15:09:31 +0000 (15:09 +0000)]
bhyve: Move lock of uart frontend to uart backend
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.
Mark Johnston [Wed, 1 May 2024 12:36:30 +0000 (08:36 -0400)]
vmrun.sh: Add arm64 support
For now, we enumerate disk devices before network devices. This is to
work around a problem wherein u-boot remaps BARs during boot in a way
that bhyve does not handle. Some discussion and experiments suggest
that this can be handled by having bhyve not map BARs during boot on
arm64; until a solution is implemented, however, this workaround is
sufficient for simple usage and doesn't have any real downsides.
The console and bootrom are specified slightly differently versus amd64,
and a few of vmrun.sh's command-line options are amd64-only.
fattime: fix fattime to timespec conversion of dates beyond 2106-02-06
It turns out that the only conversion issue was in fattime2timespec, where
multiplying the number of seconds in a day by the number of days overflowed
32-bit unsigned int for dates beyond 2106-02-07 06:28:15.
Casting one of the multiplicands as time_t forces a 64-bit multiplication on
systems where time_t is 64-bits and produces no binary changes on the one
remaining system with 32-bit time_t (namely i386).
Since the code is now tested & fixed, this change removes the fixme comments.
fattime: make the test code check beyond 32-bit time_t limits
On systems that have a 64-bit time_t, the test code now exercises the whole
range of fattime. To do this, this commit...
1. replaces the call to random() with two calls to arc4random() to
generate a 33-bit number of seconds in order to cover the entire range of
fattime [1970,2107]. (32-bits stops just short - in January 2106.)
On systems with 32-bit time_t, the extra bits are discarded and only the
time_t expressible range is tested.
2. casts time_t values passed to printf as longs and changes the format
string to match.
Now, the test code builds, runs, and exercises what it can (i.e., the whole
fattime range or the 32-bit time_t subset of it) on both 32-bit and 64-bit
time_t systems.
1. replaces calls to timet2fattime/fattime2timet with calls to
timespec2fattime/fattime2timespec. The functions got renamed shortly
after they landed in the kernel but the test code wasn't updated (see 7ea93e912bf0ef).
2. adds a utc_offset stub.
With this, the test code builds and runs as a 32-bit binary (cc -Wall -O2
-m32 subr_fattime.c).
It is the equivalent of tx_chan but for receive so rx_chan is a better
name. Initialize both using helper functions and make sure both are
displayed in the sysctl MIB.
Mark Johnston [Tue, 30 Apr 2024 21:32:38 +0000 (17:32 -0400)]
clang-format: Minor tweaks
Invert KeepEmptyLinesAtTheStartOfBlocks. We used to require an empty
line at the beginning of functions with no local variables, which I
believe is the reason for this setting. Now it is discouraged in new
code.
Tell clang-format to align consecutive macros, since we tend to do that.
clang-format's output isn't quite what we want here. Typically we have
a tab after a #define for some reason, and clang-format doesn't appear
to have an option for that. clang-format will also use a mix of tabs
and spaces to minimize indentation, which is also against our
convention. However, the result looks better with this setting than
without.
cons: Add boot option to mute boot messages after banner
This is useful for embedded systems, where it provides feedback that the
kernel has booted, but avoids printing the probe messages. If both
mutemsgs and verbose are set, verbose cancels the mute.
Additionally, this unmutes the console on panic, so a user can see what
happened leading up to the panic.
cxgbe(4): Do not read hardware registers to determine the number of ports.
PORTVEC obtained from the firmware is the authoritative source of this
information, and nports (calculated from PORTVEC) is available by the
time t4_port_init runs.
Andrew Gallatin [Mon, 29 Apr 2024 23:11:56 +0000 (19:11 -0400)]
Fix new users of MAXPHYS and hide it from the kernel namespace
In cd8537910406, kib made maxphys a load-time tunable. This made
the #define MAXPHYS in sys/param.h almost entirely obsolete, as
it could now be overridden by kern.maxphys at boot time, or by
opt_maxphys.h.
However, decades of tradition have led to several new, incorrect, uses
of MAXPHYS in other parts of the kernel, mostly by seasoned
developers. I've corrected those uses here in a mechanical fashion,
and verified that it fixes a bug in the md driver that I was
experiencing.
Since using MAXPHYS is such an easy mistake to make, it is best to
hide it from the kernel namespace. So I've moved its definition to
_maxphys.h, which is now included in param.h only for userspace.
That brings up the fact that lots of userspace programs use MAXPHYS
for different reasons, most of them probably wrong. Userspace consumers
that really need to know the value of maxphys should probably be
changed to use the kern.maxphys sysctl. But that's outside the scope
of this change.
Reviewed by: imp, jkim, kib, markj Fixes: 30038a8b4efc ("md: Get rid of the pbuf zone")
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44986
Brooks Davis [Tue, 30 Apr 2024 02:43:30 +0000 (03:43 +0100)]
libsys: don't try to expose freebsd7___semctl
This has always been in libc and never exported directly. I accidently
included it along side some freebsd11_* symbols based on a tree where I
moved semctl(2).
Fixes: df1a09ba524d0 libsys: expose a few more symbols for libc's use
This was prompted by noticing that '/var/db/portsnap' still exists on
newly-installed machines.
With this change, all mentions of portsnap(8) in the tree are gone,
except for the historical note in the AUTHORS section of manpage
phttpget(8).
locate(1) will thus start indexing again '/var/db/portsnap' on machines
where this directory still exists, which may be a good way to push
administrators to delete it.
Reviewed by: cperciva
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45023
Martin Matuska [Tue, 30 Apr 2024 09:53:06 +0000 (11:53 +0200)]
libarchive: merge bugfixes from vendor branch
#2147 archive_string: clean up strncat_from_utf8_to_utf8 (36047967a)
#2153 archive_match: check archive_read_support_format_raw()
return value (0ce1b4c38)
#2154 archive_match: turn counter into flag (287e05d53)
#2155 lha: Do not allow negative file sizes (93b11caed)
#2156 tests: setenv LANG to en_US.UTF-8 in bsdunzip test_I.c (83e8b0ea8)
Martin Matuska [Tue, 30 Apr 2024 09:41:59 +0000 (11:41 +0200)]
Update vendor/libarchive to libarchive master 83e8b0ea8
#2147 archive_string: clean up strncat_from_utf8_to_utf8 (36047967a)
#2153 archive_match: check archive_read_support_format_raw()
return value (0ce1b4c38)
#2154 archive_match: turn counter into flag (287e05d53)
#2155 lha: Do not allow negative file sizes (93b11caed)
#2156 tests: setenv LANG to en_US.UTF-8 in bsdunzip test_I.c (83e8b0ea8)
allowing to set any known LD_ parameter for the current rtld invocation,
but without polluting the activated' binary environment. In other
words, the set parameter is not exported into the environment.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D44988
The firmware clears the interrupts already and it has a better idea of
exactly what to clear for which generation of the ASIC. There is no
need for the driver to get involved.
It's possible for states to be cleaned up (through pf_detach_state()) that
have not been fully attached. For example if there's an ID conflict during
pf_state_insert().
pflow exports states from pf_detach_state(), so it can get called on such
states, but did not account for this and could end up dereferencing a NULL
state key.
Check for this in export_pflow() and do not export unattached states.
See also: https://redmine.pfsense.org/issues/15446
Sponsored by: Rubicon Communications, LLC ("Netgate")
HP van Braam [Mon, 29 Apr 2024 14:34:46 +0000 (08:34 -0600)]
ctl: Fix CTL GET EVENT STATUS NOTIFICATION valid bits
Linux as an initiator periodically sends the following to SCSI cdrom
devices: 4a 01 00 00 10 00 00 00 08 00
According to the ctl_cmd_entry for this command this is invalid which
leads to a lot of failed SCSI commands.
The mask in this commit is based off of an early draft of the mmc
standard, https://www.t10.org/ftp/t10/document.97/97-108r0.pdf,
as well as subsequent standards (mmc2 through mmc6).
This solves the issue with Linux initiators.
Signed-off-by: HP van Braam <hp@tmm.cx>
Reviewed by: imp, mav
Pull Request: https://github.com/freebsd/freebsd-src/pull/1201
pfctl_open() opens both /dev/pf and a netlink socket. Allow access to the /dev/
pf fd via pfctl_fd().
This means that libpfctl users no longer have to open /dev/pf themselves for any
calls that are not yet available in libpfctl.
A bug in release/packages/generate-ucl.sh causes package dependencies
(other than shlib depends) to not be generated correctly, meaning
packages are missing their dependencies.
generate-ucl.sh creates the UCL file by:
1. copying ${uclsource} (template.ucl) to ${uclfile}
2. appending dependencies to ${uclfile}
3. calling generate-ucl.lua on ${uclsource} to create ${uclfile}
This breaks because the dependencies added in step 2 are overwritten in
step 3.
Fix this by calling generate-ucl.lua with ${uclfile} as both the input
and output file, so anything we added to ${uclfile} is preserved.
Mark Johnston [Mon, 29 Apr 2024 14:19:27 +0000 (10:19 -0400)]
arm64/vmm: Handle VM_EXITCODE_SUSPENDED
This is required for bhyve reboot to work. In particular, unless we
suspend vcpu threads here, vm_reinit() will fail with EBUSY.
The implementation is copied from amd64; in the not-too-distant future
the amd64 and arm64 copies of vmm.c and vmm_dev.c will be merged, so
for now it's useful to minimize diffs between amd64 and arm64.
Reviewed by: corvink, andrew
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D44934
projects / FreeBSD / FreeBSD.git / log