Some implementations copy data to userspace, an operation which can in
principle fail. In preparation for adding a __result_use_check
annotation to copyin() and related functions, let implementations of
cpu_set_upcall() return an error, and check for errors when copying data
to user memory.
Reviewed by: kib, jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43100
(cherry picked from commit 7b68fb5ab2a276ccd081cc1a43cebf0fb315e952)
The VFP code expects the kernel to boot with VFP disabled, but some
boards will boot with it enabled. Make sure that vfp_init() disables
the VFP on each CPU during boot.
PR: 273752
Reviewed by: andrew
Diagnosed by: Thomas Skibo <thomas-bsd@skibo.net>
MFC after: 1 week
(cherry picked from commit ce2f34ade8b787b068085fa8a8ddd295b06c2737)
vfp_bounce() is called when handling an undefined instruction exception,
to see if we need to enable the VFP. Previously it would
unconditionally panic if the exception came from the kernel, which was
simply wrong, and it did not permit lazy initialization of VFP state in
the kernel. However, this functionality can be useful and is supported
by arm's fpu_kern_enter() implementation. Thus, relax assertions and
consume the exception if the thread was in an FPU section.
Based on a patch from Stormshield.
Reviewed by: andrew
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D42971
(cherry picked from commit 03a07de0d5ee7d58069152070c42d55f7ec32b7c)
Only panic if no undefined instruction handler matched the exception.
This can arise in practice if the VFP is enabled lazily.
While here, fix the panic string to not include a newline.
Reviewed by: andrew
Obtained from: Stormshield
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D42970
(cherry picked from commit ecc2e6deae71b69a30bf3b7e3354aba002a37d69)
This enables the use of some out-of-tree crypto libraries on arm.
No functional change intended, there are no callers of this function in
the tree currently.
Reviewed by: andrew
MFC after: 1 week
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D42969
(cherry picked from commit a6a481eaa2e0f02e24b874f1a08bb494a68972c0)
Filter functions are deprecated, and unused in the tree. If either of
the filter or filterarg arguments to bus_dma_tag_create() are non-NULL,
print a warning.
This is a direct commit to stable/14.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42897
In uma_set_align_mask(), ensure that the passed value doesn't have its
highest bit set, which would lead to problems since keg/zone alignment
is internally stored as signed integers. Such big values do not make
sense anyway and indicate some programming error. A future commit will
introduce checks for this case and other ones.
Reviewed by: kib, markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42262
(cherry picked from commit 3d8f548b9e5772ff6890bdc01f7ba7b76203857d)
There's no point in setting 'arm_dcache_align_mask' before the
function's end.
Reviewed by: markj, kib
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42261
(cherry picked from commit 1bce6f951a902f03bfb354f5b11473a0d12b3d7d)
Create the uma_get_cache_align_mask() accessor and put it in a separate
private header so as to minimize namespace pollution in header/source
files that need only this function and not the whole 'uma.h' header.
Make sure the accessors have '_mask' as a suffix, so that callers are
aware that the real alignment is the power of two that is the mask plus
one. Rename the stem to something more explicit. Rename
uma_set_cache_align_mask()'s single parameter to 'mask'.
Hide 'uma_align_cache' to ensure that it cannot be set in any other way
then by a call to uma_set_cache_align_mask(), which will perform sanity
checks in a further commit. While here, rename it to
'uma_cache_align_mask'.
This is also in preparation for some further changes, such as improving
the sanity checks, eliminating internal resolving of UMA_ALIGN_CACHE and
changing the type of the 'uma_cache_align_mask' variable.
Reviewed by: markj, kib
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42258
(cherry picked from commit dc8f7692fd1de628814f4eaf4a233dccf4c92199)
Make sure that we don't try to copy with a negative resid.
Make sure that we don't walk off the end of the iovec array.
Reviewed by: kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42098
(cherry picked from commit 8fd0ec53deaad34383d4b344714b74d67105b258)
The sysctl knob 'vm.pmap.pv_entry_max' becomes a loader tunable since
7ff48af704 (Allow a specific setting for pv entries) but is fetched
from system environment 'vm.pmap.pv_entries'. That is inconsistent and
obscure.
This reverts 36e1b9702e (Correct the tunable name in the message).
PR: 231577
Reviewed by: jhibbits, alc, kib
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D42274
(cherry picked from commit 02320f64209563e35fa371fc5eac94067f688f7f)
The folder is a mess so start moving stuff into sub-directories.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D41907
(cherry picked from commit 580d00f42fdd94ce43583cc45fe3f1d9fdff47d4)
madt_table_data contains an array of pointers for each CPU and was
allocated on the stack. If MAXCPU is raised to a sufficiently large
value this can overflow the kernel stack. Cap the stack growth by
using GIC_MAXCPU instead as for other parts of the gicv1/v2 driver in
commit a0e20c0ded.
Suggested by: andrew
Reviewed by: andrew, emaste
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D41800
(cherry picked from commit d0af08c4ba3e400049d246d72401ce36d3bee98a)
For amd64, i386, arm, and riscv, i.e. all architectures except arm64,
the custom implementation is provided since we maintain the bitmask of
active CPUs anyway.
Arm64 uses somewhat naive iteration over CPUs and match current vmspace'
pmap with the argument. It is not guaranteed that vmspace->pmap is the
same as the active pmap, but the inaccuracy should be toleratable.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32360
This target produces a C file not an object file, so using ctfconvert on
it should not be attempted. This keeps it in sync with all other uses of
fw_stub.awk, squashes a warning seen during the build of TEGRA124 on
FreeBSD and avoids the same issue failing the build on non-FreeBSD (such
errors are #ifdef'ed into being warnings on FreeBSD in ctfconvert, which
should be revisited in the future).
Reviewed by: manu
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D41542
Add support for the gpio controller found in the ZynqMP SoC.
The registers are the same as the Zynq 7000, just the number of
banks/pins per banks differs.
Sponsored by: Beckhoff Automation GmbH & Co. KG
MFC after: 2 weeks
All other Zynq SoCs have the same GPIO controller, the only difference
is the number of banks/pins so make this driver more generic to add
other SoCs more easily.
No functional changes intended.
Sponsored by: Beckhoff Automation GmbH & Co. KG
MFC after: 2 weeks
Following the removal of general MIPS support, there's no longer a need
to have the AHB bus-frontend in place, which according to Linux sources
also isn't used with any non-MIPS SoCs. For simplicity, PCI bus support
is only made conditional on the main one again, i. e. device ath_pci is
removed, and built into the main module, i. e. if_ath_pci.ko obsoleted,
respectively.
Effectively, this reverts the following commits and associated changes:
dba9c85977e849bb3ecb
Approved by: adrian
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D41354
The GICv2 can only send IPIs to 8 CPUs. Because of this it should only
be in machines with no more than 8 cores.
Create a new macro to hold this limit to reduce the size of the softc.
Reviewed by: emaste
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41322
If the unwinder somehow ends up with a stack pointer that lies outside
the stack, then an attempt to dereference can lead to a fault, which
causes the kernel to panic again and unwind the stack, which leads to a
fault...
Add kstack_contains() checks at points where we dereference the stack
pointer. This avoids the aforementioned infinite loop in one case I hit
where some OpenSSL assembly code apparently confuses the unwinder.
Reviewed by: jhb
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D41210
There is no need for this to be versioned after the removal of armv4/v5
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41139
Previously we had an armv4/v5 and armv6/v7 copy of the pmap header. As
we have removed armv4/v5 support we can now merge the armv6/v7 code
into pmap.h
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41138
Previously we had an armv4/v5 and armv6/v7 copy of the cpu.h header. As
we have removed armv4/v5 support we can now merge the armv6/v7 code
into cpu.h
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41137
Previously we had an armv4/v5 and armv6/v7 implementation of the atomic
operations. As we have removed armv4/v5 support we can now merge the
armv6/v7 code into atomic.h
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41135
These includes were added for armv4 and armv5 support. Remove them as
this has been removed from the tree.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41133
Use of compiler builtin ffs/ctz functions will result in optimized
instruction sequences when possible, and fall back to calling a function
provided by the compiler run-time library. We have slowly shifted our
platforms to take advantage of these builtins in 60645781d6 (arm64),
1c76d3a9fb (arm), 9e319462a0 (powerpc, partial).
Some platforms still rely on the libkern implementations of these
functions provided by libkern, namely riscv, powerpc (ffs*, flsll), and
i386 (ffsll and flsll). These routines are slow, as they perform a
linear search for the bit in question. Even on platforms lacking
dedicated bit-search instructions, such as riscv, the compiler library
will provide better-optimized routines, e.g. by using binary search.
Consolidate all definitions of these functions (whether currently using
builtins or not) to libkern.h. This should result in equivalent or
better performing routines in all cases.
One wart in all of this is the existing HAVE_INLINE_F*** macros, which
we use in a few places to conditionally avoid the slow libkern routines.
These aren't easily removed in one commit. For now, provide these
defines unconditionally, but marked for removal after subsequent
cleanup.
Removal of the now unused libkern routines will follow in the next
commit.
Reviewed by: dougm, imp (previous version)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40698
Add support for GPIO internal pull up/down configuration on RPi4 family.
BCM2711 SoC on 4th generation Raspberry Pi changed the way to configure
its GPIO pins' internal pull up/down resistors. NetBSD already have
support for this change, and port it to FreeBSD is trivial.
This patch, based on the NetBSD commit adds the appropriate method for
BCM2711 and now we can properly configure the GPIO pins' pull status.
PR: 256372
Reviewed by: mhorne
Obtained from: NetBSD bb88cfa64ad8
Pull Request: https://github.com/freebsd/freebsd-src/pull/746
