sound: Get rid of snd_clone and use DEVFS_CDEVPRIV(9)
Currently the snd_clone framework creates device nodes on-demand for
every channel, through the dsp_clone() callback, and is responsible for
routing audio to the appropriate channel(s). This patch gets rid of the
whole snd_clone framework (including any related sysctls) and instead
uses DEVFS_CDEVPRIV(9) to handle device opening, channel allocation and
audio routing. This results in a significant reduction in code size as
well as complexity.
Behavior that is preserved:
- hw.snd.basename_clone.
- Exclusive access of an audio device (i.e VCHANs disabled).
- Multiple processes can read from/write to the device.
- A device can only be opened as many times as the maximum allowed
channel number (see SND_MAXHWCHAN in pcm/sound.h).
- OSSv4 compatibility aliases are preserved.
Behavior changes:
Only one /dev/dspX device node is created (on attach) for each audio
device, as opposed to the current /dev/dspX.Y devices created by
snd_clone. According to the sound(4) man page, devices are not meant to
be opened through /dev/dspX.Y anyway, so it is best if we do not create
device nodes for them in the first place. As a result of this, modify
dsp_oss_audioinfo() to print /dev/dspX in the "ai->devnode", instead of
/dev/dspX.Y.
Sponsored by: The FreeBSD Foundation
MFC after: 2 months
Reviewed by: dev_submerge.ch, bapt, markj
Differential Revision: https://reviews.freebsd.org/D44411
Colin Percival [Thu, 11 Apr 2024 16:24:59 +0000 (09:24 -0700)]
release/Makefile.vm: Support read-only ports tree
Build qemu (if needed) with WRKDIRPREFIX=/tmp/ports DISTDIR=/tmp/distfiles
so that we can have a read-only /usr/ports and don't contaminate it. This
became an issue when I enabled parallel release building, since one image
might be creating its ports.txz file at the same time as we're building
qemu as a prerequisite for building another image.
Mark Johnston [Wed, 10 Apr 2024 14:10:10 +0000 (10:10 -0400)]
arm64/vmm: Define a dummy _start symbol in vmm_hyp_blob.elf
To silence a linker warning about _start being missing. This blob
contains code executed at EL2 and is only meant to be entered via
exception handlers.
Reviewed by: bz, emaste
Fixes: 47e073941f4e ("Import the kernel parts of bhyve/arm64")
Differential Revision: https://reviews.freebsd.org/D44735
Cristian Marussi [Mon, 11 Dec 2023 08:33:01 +0000 (08:33 +0000)]
scmi: Introduce a new SCMI API and port CLK SCMI driver to it
Expose new scmi_buf_get/put API methods to build and send messages;
command request descriptors are now pre-allocated when the SCMI core is
initialized and kept in a free list, instead of being allocated on the
stack of the caller of the SCMI request.
Dynamically allocated descriptors enable the SCMI core to keep around
and track outstanding transactions for as long as needed, outliving the
lifetime of the caller stack: this allows tracking of late or missing
replies and it will be needed when adding support for SCMI transports
that allows for more messages to be inflight concurrently.
Move the existing CLK SCMI driver to the new API.
Reviewed by: andrew
Tested on: Arm Morello Board
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43046
scmi: Add SCMI message tracking and centralize tx/rx logic
In order to be able to support also new, more parallel, SCMI transports
that by nature can allow multiple concurrent commands to be in-flight,
pending a reply, we must be able to use the sequence number provided in
the SCMI messages to track the message status, matching commands and
replies while keeping track of timeouts and duplicates.
Add the needed message tracking machinery in the core SCMI stack and
move the residual common tx/rx logic from the specific transports to
the core SCMI stack, while adding one more interface to let the
transports customize ther behaviour.
Reviewed by: andrew
Tested on: Arm Morello Board
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43045
scmi: Add new SCMI interfaces for init and message processing
Introduce a couple of new SCMI interface methods to allow centralized
initialization of transport-specific features and a couple of methods
to handle message reception from the SCMI core.
Move SCMI SMT related calls out of the core common SCMI code into the
transport specific layers Mailbox/SMC.
Make SCMI Mailbox/SMC transports use the new interface methods for
initialization and message reception.
Reviewed by: andrew
Tested on: Arm Morello Board
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43044
scmi: Protect SCMI/SMT channels from concurrent transmissions
The SCMI/SMT memory areas are used from the agent and the platform as
channels to exchage commands and replies.
Once the platform has completed its processing and a reply is ready to
be read from the agent, the platform will relinquish the channel to the
agent by setting the CHANNEL_FREE bits in the related SMT area.
When this happens, though, the agent has still to effectively read back
the reply message and any other concurrent request happened to have been
issued in the meantime will have been to be hold back until the reply
is processed or risk to be overwritten by the new request.
The base->mtx lock that currently guards the whole scmi_request()
operation is released when sleeping waiting for a reply, so the above
mentioned race can still happen or, in a slightly different scenario,
the concurrent transmission could just fail, finding the channel busy,
after having sneaked through the mutex.
Adding a new mechanism to let the agent explicitly acquire/release the
channel paves the way, in the future, to remove such central commmon
lock in favour of new dedicated per-transport locking mechanisms, since
not all transports will necessarily need the same level of protection.
Add a flag, controlled by the agent, to mark when the channel has an
inflight command transaction still pending to be completed and make the
agent spin on it when queueing multiple concurrent messages on the same
SMT channel.
Reviewed by: andrew
Tested on: Arm Morello Board
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43043
When the system is cold, the SCMI stack processes commands in polling
mode with the current polling mechanism being a check of the status
register in the mailbox controller to see if there is any pending
doorbell request.
Anyway, the completion interrupt is optional by the SCMI specification
and a system could have been simply designed without it: for this
reason polling on the mailbox controller status registers is not going
to work in all situations.
Moreover even alternative SCMI transports based on shared memory, like
SMC, will not have at all a mailbox controller to poll for.
On the other side, the associated SCMI Shared Memory Transport defines
dedicated channel flags and status bits that can be used by the agent to
explicitly request a polling-based transaction, even if the completion
interrupt was available, and to check afterwards when the platform has
completed its processing on the outstanding command.
Use SCMI/SMT specific mechanism to process transactions in polling mode.
Reviewed by: andrew
Tested on: Arm Morello Board
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43042
Add a few new common public scmi_shmem methods to be used to handle SCMI
shared memory areas from multiple transports; while doing that review
the shared memory accesses to read only the SMT header fields strictly
relevant to the SCMI message processing.
Move all the SCMI shmem related code to the existing scmi_shmem.c file
and add a new dedicated scmi_shmem.h header.
Introduce some commonly needed message header manipulation macros.
Reviewed by: andrew
Tested on: Arm Morello Board
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43041
Bojan Novković [Tue, 9 Apr 2024 19:02:12 +0000 (21:02 +0200)]
vm: improve kstack_object pindex calculation to avoid pindex holes
This commit replaces the linear transformation of kernel virtual
addresses to kstack_object pindex values with a non-linear
scheme that circumvents physical memory fragmentation caused by
kernel stack guard pages. The new mapping scheme is used to
effectively "skip" guard pages and assign pindices for
non-guard pages in a contiguous fashion.
The new allocation scheme requires that all default-sized kstack KVAs
come from a separate, specially aligned region of the KVA space.
For this to work, this commited introduces a dedicated per-domain
kstack KVA arena used to allocate kernel stacks of default size.
The behaviour on 32-bit platforms remains unchanged due to a
significatly smaller KVA space.
Aside from fullfilling the requirements imposed by the new scheme, a
separate kstack KVA arena facilitates superpage promotion in the rest
of kernel and causes most kstacks to have guard pages at both ends.
Jessica Clarke [Mon, 19 Feb 2024 22:40:24 +0000 (22:40 +0000)]
bhyve: Fix arm64 PCI I/O range to match FDT
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).
Jessica Clarke [Sat, 17 Feb 2024 01:44:51 +0000 (01:44 +0000)]
bhyve: Support legacy PCI interrupts on arm64
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.
Mark Johnston [Wed, 3 Apr 2024 17:45:06 +0000 (13:45 -0400)]
libvmmapi: Conditionalize compilation of some functions
Hide definitions of several functions that currently don't have
implementatations in the arm64 vmm port. In particular, add a
WITH_VMMAPI_SNAPSHOT preprocessor variable that can be used to enable
compilation of save/restore functions, and conditionalize compilation of
some functions only used by amd64 bhyve. If in the long term they
remain amd64-only, they can move to vmmapi_machdep.c, but for now it's
not clear to me that that's the right thing to do.
Mark Johnston [Wed, 3 Apr 2024 17:44:40 +0000 (13:44 -0400)]
bhyve: Push option parsing down into bhyverun_machdep.c
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.
Mark Johnston [Wed, 3 Apr 2024 17:11:37 +0000 (13:11 -0400)]
bhyve: Add PCI mappings for arm64
- 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.
Mark Johnston [Wed, 3 Apr 2024 17:11:24 +0000 (13:11 -0400)]
bhyve: Do not compile PCI passthrough support on arm64
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.
Mark Johnston [Wed, 3 Apr 2024 17:09:32 +0000 (13:09 -0400)]
libvmmapi: Make vm_raise_msi() a common function
Currently, bhyve PCI emulation uses vm_lapic_msi() to raise an MSI in
the guest. The arm64 port has a similar function, vm_raise_msi().
Add vm_raise_msi() on amd64 as well and have it simply call
vm_lapic_msi() so that bhyve can use a common, generically named
function.
Mark Johnston [Wed, 3 Apr 2024 17:01:31 +0000 (13:01 -0400)]
libvmmapi: Make memory segment handling a bit more abstract
libvmmapi leaves a hole at [3GB, 4GB) in the guest physical address
space. This hole is not used in the arm64 port, which maps everything
above 4GB. This change makes the code a bit more general to accomodate
arm64 more naturally. In particular:
- Remove vm_set_lowmem_limit(): it is unused and doesn't have
well-defined constraints, e.g., nothing prevents a consumer from
setting a lowmem limit above the highmem base.
- Define a constant for the highmem base and use that everywhere that
the base is currently hard-coded.
- Make the lowmem limit a compile-time constant instead of a vmctx field.
- Store segment info in an array.
- Add vm_get_highmem_base(), for use in bhyve since the current value is
hard-coded in some places.
Mark Johnston [Wed, 3 Apr 2024 16:56:22 +0000 (12:56 -0400)]
libvmmapi: Move PCI passthrough ioctl wrappers into a separate file
The arm64 port doesn't implement PCI passthrough and in particular
doesn't define the ioctls used by these wrappers. It might be that the
ppt ioctl interface will require modification to support arm64. Until
that's sorted out one way or another, put this code in a separate file
so that it's easy to conditionally compile.
Mark Johnston [Wed, 3 Apr 2024 16:55:54 +0000 (12:55 -0400)]
libvmmapi: Split the ioctl list into MI and MD lists
To enable use in capability mode, libvmmapi needs a list of all the
ioctls that might be invoked on the vmm device handle. Some of these
ioctls are amd64-specific. Move the ioctl list to vmmapi_machdep.c and
define a list of MI ioctls so that the arm64 port can build its own list
without duplicating common ioctls. No functional change intended.
Mark Johnston [Wed, 3 Apr 2024 16:52:25 +0000 (12:52 -0400)]
libvmmapi: Move some ioctl wrappers to vmmapi_machdep.c
ioctls relating to segments and various x86-specific interrupt
controllers are easy candidates to move to vmmapi_machdep.c.
In vmmapi.h I'm just ifdefing MD prototypes for now. We could instead
split vmmapi.h into multiple headers, e.g., vmmapi.h and
vmmapi_machdep.h, but it's not obvious to me yet that that's the right
approach.
Mark Johnston [Wed, 3 Apr 2024 16:50:21 +0000 (12:50 -0400)]
bhyve: Add FDT building code for arm64
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
Mark Johnston [Wed, 3 Apr 2024 16:48:45 +0000 (12:48 -0400)]
bhyve: Provide optional libfdt linking
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.
sys_procctl(): Make it clear that negative commands are invalid
An initial reading of the preamble of sys_procctl() gives the impression
that no test prevents a malicious user from passing a negative commands
index (in 'uap->com'), which is soon used as an index into the static
array procctl_cmds_info[].
However, a closer examination leads to the conclusion that the existing
code is technically correct. Indeed, the comparison of 'uap->com' to
the nitems() expression, which expands to a ratio of sizeof(), leads to
a conversion of 'uap->com' to an 'unsigned int' as per Usual Arithmetic
Conversions/Integer Promotions applied by '<=', because sizeof() returns
'size_t' values, and we define 'size_t' as an equivalent of 'unsigned
int' (which is not mandated by the standard, the latter allowing, e.g.,
integers of lower ranks).
With this conversion, negative values of 'uap->com' are automatically
ruled-out since they are converted to very big unsigned integers which
are caught by the test. An analysis of assembly code produced by LLVM
16 on amd64 and practical tests confirm that no exploitation is possible.
However, the guard code as written is misleading to readers and might
trip up static analysis tools. Make sure that negative values are
explicitly excluded so that it is immediately clear that EINVAL will be
returned in this case.
Build tested with clang 16 and GCC 12.
Approved by: markj (mentor)
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
exit(3) man page shows __cxa_atexit(3,) instead of __cxa_atexit(3), in a
particular section. It seems the comma gets inside the parenthesis and
with an extra space, it can be viewed as expected.
Colin Percival [Wed, 10 Apr 2024 03:27:19 +0000 (20:27 -0700)]
release: Don't reuse disc1/bootonly directories
The disc1 and bootonly directories have files distributed into them
for use in "full" and "mini" images; the former are disc1.iso and
memstick.img, and the latter is bootonly.iso and mini-memstick.img.
Unfortunately the scripts which package a directory tree into an ISO
or memory stick image also modify the directory, for example to
create an appropriate /etc/fstab file; so creating two images at the
same time breaks.
Resolve this by copying disc1 to disc1-disc1 and disc1-memstick,
and copying bootonly to bootonly-bootonly and bootonly-memstick,
before using those directories for constructing the ISO+memstick
images.
Colin Percival [Wed, 10 Apr 2024 03:25:34 +0000 (20:25 -0700)]
release: make -j compat: cd inside subshell
Place instances of "cd foo && bar" inside subshells for compatibility
with modern make(8) which uses a single shell for the duration of a
makefile target.
bcm2838_xhci(4) is a shim for the XHCI controller on the Raspberry Pi 4B
SoC. It loads the controller's firmware before passing control to the
normal xhci(4) driver.
When xhci(4) is built as a module (and not in the kernel), bcm2838_xhci
is not built at all and the RPi4's XHCI controller won't attach due to
missing firmware.
To fix this, build a new module, bcm2838_xhci.ko, which depends on
xhci.ko. For the dependency to work correctly, also modify xhci to
provide the 'xhci' module in addition to the 'xhci_pci' module it
already provided.
Since bcm2838_xhci is specific to a quirk of the RPi4 SoC, only build
the module for AArch64.
If userpath is not SHM_ANON, then copy it in early so ktrace(2) can
record it. Without this change, ktrace(2) will attempt to strcpy a
userspace string and trigger a page fault.
John Baldwin [Tue, 9 Apr 2024 22:02:58 +0000 (15:02 -0700)]
NOTES: Tidy entries for SATA controllers
- Add typical comments after device entries (copied from amd64
GENERIC)
- Add an entry for 'device ada'. Normally this is pulled in via
'device sd', but is documented in ada(4) and can be used to include
ATA/SATA disk support in a kernel without SCSI disk support.
periodic/daily/801.trim-zfs: Add a daily zfs trim script
As mentioned in zpoolprops(7), on some SSDs, it may not be desirable to
use ZFS autotrim because a large number of trim requests can degrade
disk performance; instead, the pool should be manually trimmed at
regular intervals.
Add a new daily periodic script for this purpose, 801.trim-zfs. If
enabled (daily_trim_zfs_enable=YES; the default is NO), it will run a
'zpool trim' operation on all online pools, or on the pools listed in
'daily_trim_zfs_pools'.
The trim is not started if the pool is degraded (which matches the
behaviour of the existing 800.scrub-zfs script) or if a trim is already
running on that pool. Having autotrim enabled does not inhibit the
periodic trim; it's sometimes desirable to run periodic trims even with
autotrim enabled, because autotrim can elide trims for very small
regions.
John Baldwin [Tue, 9 Apr 2024 21:55:40 +0000 (14:55 -0700)]
pci_host_generic: Tolerate range resource allocation failures
QEMU for armv7 includes a PCI memory range whose CPU address is
greater than 4GB. This falls outside the range of armv7's global
mem_rman used by the nexus driver. As a result, pcib0 fails to
attach blocking all PCI devices.
Instead, change the driver to be a bit more tolerant. If allocating a
resource for a range fails, don't fail attaching the entire driver,
but do skip adding the associated PCI range to the relevant rman in
the pcib driver. This will prevent child devices from using BARs that
allocate from this range. In the case of QEMU on armv7 devices can
still allocate from an earlier PCI memory range that is within the
32-bit address space (and in fact none of the firmware-assigned memory
BARs use addresses from the upper range).
While here, reorder the operations on I/O ranges a bit: 1) print the
range under bootverbose first (rather than last) so that the range is
printed before any relevant errors for the range, 2) move
rman_manage_region last after the parent resource has been set and
allocated.
projects / FreeBSD / FreeBSD.git / log