Read the elf note to decide when to set the guard page on arm64.
Reviewed by: kib
Sponsored by: Arm Ltd
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39452
As with watchpoints allow the kernel debugger to set hardware
breakpoints on arm64.
These have been tested to work in both the ddb and gdb backends.
Reviewed by: jhb (earlier version)
Sponsored by: Arm Ltd
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D44355
Support the use of hardware breakpoints in the kernel gdb stub.
Reviewed by: jhb (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D44354
As with hardware watchpoints add support for hardware breakpoints. The
command is only enabled on architectures that report support for them.
Currently no architectures do, however arm64 will add support in a
future change.
Reviewed by: jhb (earlier version)
Sponsored by: Arm Ltd
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D22191
To allow for hardware breakpoints it is useful to reuse the same
management code. Start to generalise the code by moving common data
into a new struct and pas this to internal functions to work with.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D44461
Add ofw_bus_if.h to SRCS so that this will always be generated so this
can build standalone, or when FDT isn't in the kernel.
Fixes: ac83063d37 (for LINT-ACPI)
Sponsored by: Netflix
[X86][AVX512BF16] Add a few missing insert/extract patterns
These are really the same as the f16 (and i16) instructions, but we need
them for any type that can occur.
Merge commit 2e4e04c59043 from llvm-project (by Phoebe Wang):
[X86][BF16] Do not lower to VCVTNEPS2BF16 without AVX512VL (#86395)
Fixes: #86305
These should fix "fatal error: error in backend: Cannot select: t71:
v32bf16 = insert_subvector t67, t64, Constant:i32<16>" when building the
misc/ncnn port.
PR: 278305
Reported by: yuri
MFC after: 1 month
The author reported that this patch was needed to avoid
crashes on a fairly busy RISC-V system. The author did not
provide details w.r.t. the crashes. Although I
have not seen any such crash, the patch looks reasonable
and I have not found any regressions when testing it.
Since "rdirplus" is not a default option, the patch is
only needed if you are doing NFS mounts with the "rdirplus"
mount option and seeing crashes related to the name cache.
MFC after: 1 week
During a minor refactoring two years ago (part of 2486b446), the newly
created enum used the wrong part number - MCP7491x instead of MCP7941x. The
device description string got the same transposition of digits.
This change swaps the digits back to what they should be.
Reviewed by: emaste, tsoome, imp
Differential Revision: https://reviews.freebsd.org/D44436
1. Both trackbuf and vrfybuf are initialized to
zero (NULL). While it's okay to initialize pointers
to zero, to keep consistency, as they're explicitly
pointers, it's better to just use NULL ((void *)0)
instead of 0 (both are equivalent to the compilers).
2. Call free() for both trackbuf and vrfybuf after
their job has been done.
3. Remove the register keyword. Compilers generally
ignore this keyword (except for very very old compilers
and CPUs).
4. Remove the ctype.h header. It's not being used
anywhere in the file.
Signed-off-by: rilysh <nightquick@proton.me>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1059
On systems utilizing ZFS, default to creating a ZFS dataset for a new
user's home directory if the parent directory resides on a ZFS dataset.
Add a flag that disables this behavior if the administrator explicitly
does not want it.
If run during installation from within a chroot, set mountpoint to legacy
after dataset creation and mount directly into the chroot. Then umount
and reset the mountpoint to inherit from parent.
Also support ZFS default encryption on user's home directory.
Feedback by: delphij
Reviewed by: imp, kevans
Pull Request: https://github.com/freebsd/freebsd-src/pull/881
Hot-unplugging a sound device, such as a USB sound card, whilst being
consumed by an application, results in an infinite loop until either the
application closes the device's file descriptor, or the channel
automatically times out after hw.snd.timeout seconds. In the case of a
detach however, the timeout approach is still not ideal, since we want
all resources to be released immediatelly, without waiting for N seconds
until we can use the bus again.
The timeout mechanism works by calling chn_sleep() in chn_read() and
chn_write() (see pcm/channel.c) in order to send the thread to sleep,
using cv_timedwait_sig(). Since chn_sleep() sets the CHN_F_SLEEPING flag
while waiting for cv_timedwait_sig() to return, we can test this flag in
pcm_unregister() (called during detach) and wakeup the sleeping
thread(s) to immediately kill the channel(s) being consumed.
Sponsored by: The FreeBSD Foundation
MFC after: 2 months
PR: 194727
Reviewed by: dev_submerge.ch, bapt, markj
Differential Revision: https://reviews.freebsd.org/D43545
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
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.
MFC after: 5 days
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: 47e073941f ("Import the kernel parts of bhyve/arm64")
Differential Revision: https://reviews.freebsd.org/D44735
Make basic-cloudinit available both in qcow2 and raw formats
MFC After: 1 week
Reviewed by: Allanjude
Sponsored by: OVHCloud
Differential Revision: https://reviews.freebsd.org/D44747
Add an SCMI transport driver based on the virtio-scmi backend.
Reviewed by: andrew, bryanv
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43048
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
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
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
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
Using the SCMI transport interface add a new SMC transport to the
SCMI stack.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43040
