Support socdev_va on arm and ensure the variable is available on arm64.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43359
- In pmap_bootstrap_san(), allocate the root PTPs for the shadow maps.
(For KASAN, this is done earlier since we need to do some special
bootstrapping for the kernel stack.)
- Adjust ifdefs to include KMSAN.
- Expand the shadow maps when pmap_growkernel() is called.
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D43405
- Move pmap_bootstrap_allocate_kasan_l2() close to the place where it is
actually used.
- Simplify pmap_bootstrap_allocate_kasan_l2() a bit: eliminate some
unneeded variables and zero and exclude each 2MB mapping as we go
rather than doing that all at once. Excluded regions will be
coalesced.
- As a consequence of the previous point, ensure that we do not zero a
preexisting 2MB mapping.
- Simplify pmap_bootstrap_san() and prepare it to work with KMSAN.
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D43404
The break-before-make operation required to promote or demote a
superpage leaves a window where the KMSAN runtime can trigger a fatal
data abort. More specifically, the code in pmap_update_entry() which
executes after ATTR_DESCR_VALID is cleared may implicitly attempt to
access KMSAN context via curthread, but we may be promoting or demoting
a 2MB page containing the curthread structure.
Reviewed by: imp
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D43158
This works identically to amd64. In particular, only the
bus_dma_bounce_impl busdma implementation handles KMSAN at the moment.
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D43157
This is mostly a copy of amd64's msan.h, except that we currently do not
avoid shadowing the kernel itself, and we need a more restrictive upper
bound in kmsan_md_unsupported() to avoid probing non-existent shadow
mappings of device mappings.
Reviewed by: imp
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D43156
- Call kmsan_intr_enter() when an exception occurs. This ensures that
code running in the exception context does not clobber thread-local
KMSAN state.
- Ensure that stack memory containing trap frames is treated as
initialized.
Co-authored-by: Alexander Stetsenko <alex.stetsenko@klarasystems.com>
Reviewed by: imp
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D43155
Both are the same size as the kernel map.
Reviewed by: imp
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D43154
Allows the development, testing and deployment of netmap(4)-based code
on arm64 without having to recompile the kernel. netmap(4) is already
in the amd64 and powerpc64 default configs, so it does not seem
unreasonable to also provide it on arm64 by default.
Note that netmap(4) is useful even on systems without NIC that fully
support it.
Reviewed by: vmaffione
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D43702
we leave `options CAMDEBUG` enabled, so that when needed, CAM debugging
can be enabled *as needed*, rather than setting a default of everything.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/798
ACPICA is using flexible arrays since 20230331 and it broke aarch64
build.
--- acpi_iort.o ---
/usr/src/sys/arm64/acpica/acpi_iort.c:103:4: error: field 'data' with
variable sized type 'union (unnamed union at
/usr/src/sys/arm64/acpica/acpi_iort.c:98:2)' not at the end of a struct
or class is a GNU extension [-Werror,-Wgnu-variable-sized-type-not-at-end]
103 | } data;
| ^
Reported by: bapt
Tested by: bapt
pmap_san_bootstrap() doesn't really do much, and it was hard-coding the
the bootstrap stack size defined in locore.S. Moreover, the name is a
bit confusing given the existence of pmap_bootstrap_san(). Just remove
it and call kasan_init_early() directly like we do on amd64. It will
not be used by KMSAN in a forthcoming patch series.
No functional change intended.
MFC after: 1 week
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D43403
When booting a KMSAN kernel on an Ampere Altra, I've seen some boot time
hangs when the XHCI controller driver attempts to allocate memory for
32-bit DMA. The system boots fine with a GENERIC kernel; I believe that
the additional memory requirements of KMSAN push it over the edge. The
system has a bit less than 2GB of RAM below the 4GB boundary.
Allocate a new freelist to segregate memory below 4GB, as we do on
amd64, so that such memory allocation failures are less likely to occur.
Reviewed by: alc
MFC after: 1 month
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D43503
On RISC-V, the root PIC (whether the PLIC or, as will be the case in
future, the local interrupt controller) cannot send IPIs, relying on
another means to trigger the necessary software interrupts (firmware
calls), but there are upcoming standard devices that will be able to
inject them, so we can't just put the firmware calls in the root PIC
driver.
Thus, split out a new intr_ipi_dev from intr_irq_root_dev to use for
sending IPIs. New devices can be registered with a given priority up
until the first IPI is set up, when the best device seen so far gets
frozen as the IPI device to use.
Reviewed by: mhorne
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D35899
The arm and arm64 implementations of dispatching IPIs via PIC_IPI_SEND
are almost identical, and entirely MI with the lone exception of a
single store barrier on arm64 (that is likely either redundant or needed
on arm too). Thus, de-duplicate this code by moving it to INTRNG as a
generic IPI glue framework. The ipi_* functions remain declared in MD
smp.h headers and implemented in MD code, but are trivial wrappers
around intr_ipi_send that could be made MI, at least for INTRNG ports,
at a later date.
Note that, whilst both arm and arm64 had an ii_send member in intr_ipi
to abstract over how to send interrupts,, they were always ultimately
using PIC_IPI_SEND, and so this complexity has been removed. A follow-up
commit will re-introduce the same flexibility by instead allowing a
device other than the root PIC to be registered as the IPI sender.
As part of this, strengthen a MAXCPU assertion that was missed in commit
2f0b059eea ("intrng: switch from MAXCPU to mp_ncpus") (which itself is
mis-titled).
Reviewed by: mmel, mhorne
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D35898
The static irq_root_ipicount variable is only ever written to (with the
value passed to irq_root_ipicount), never read. Moreover, the bcm2836
driver, as used by the Raspberry Pi 2B and 3A/B (but not 4, which uses a
GIC-400, though does have the legacy interrupt controller present too)
passes 0 as ipicount, despite implementing IPIs. It's thus inaccurate
and serves no purpose, so should be removed.
Reviewed by: mmel, imp, mhorne
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D35897
- Implement bus_map/unmap_resource pulling bits from the previous
thunder_pem_activate/deactivate_resource.
- Use bus_generic_rman_* in various routines for memory and I/O port
resources.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43439
There is a mistake in the cast, resulting in a truncated read to tmp64.
Switch from int to uint64_t, and adjust the other casts for clarity.
Add a comment explaining why we do this at all.
Reported by: dfr
Reviewed by: dfr, mmel, emaste, jhb (all a previous version)
PR: 276406
MFC after: 3 days
Fixes: a67687fcd8 ("Use native-sized accesses when accessing memory from kdb")
Differential Revision: https://reviews.freebsd.org/D43479
There is a mistake in the cast, resulting in a truncated read to tmp64.
Switch from int to uint64_t, and adjust the other casts for clarity.
Add a comment explaining why we do this at all.
Reported by: dfr
Reviewed by: dfr, mmel, emaste, jhb (all a previous version)
PR: 276406
MFC after: 3 days
Fixes: a67687fcd8 ("Use native-sized accesses when accessing memory from kdb")
The code which installs the kernel symbol table wasn't being compiled
because the file did not include opt_ddb.h
Reviewed by: kevans emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43490
_Alignof(expression) is a non-standard extension. This is not allowed
in gnu11 and gnu17 which follow the C11 standard _Alignof(type).
Reviewed by: arichardson, imp, jhb
Fixes: 4a9cd9fc22 amd64 db_trace: Reject unaligned frame pointers
Fixes: 7ccaf76a27 riscv db_trace: Ensure trapframe pointer is suitably aligned.
Fixes: 638c68897f arm64 db_trace: Ensure trapframe pointer is suitably aligned.
Differential Revision: https://reviews.freebsd.org/D43409
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: mhorne
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43196
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: emaste, imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43195
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: emaste, imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43194
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43192
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: mhorne
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43191
dwc3 is big enough to have its own subdirectory.
While here only make it depend on kernel option dwc3 and rk_dwc3
without any SOC options.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43190
No need to keep it under sys/arm64/rockchip/clk
It's easier to find which controller we support by looking under one directory.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43189
No need to keep it under sys/arm64/rockchip
It's easier to find which controller we support by looking under one directory.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43186
No need to keep it under sys/arm64/rockchip
It's easier to find which controller we support by looking under one directory.
Sponsored by: Beckhoff Automation GmbH & Co. KG
No need to keep it under sys/arm64/rockchip
It's easier to find which controller we support by looking under one directory.
While here remove the condition on SOC option, device rk_i2c is enough as all
Rockchip SoC that we support have this controller.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43184
Issue data claim command after every chunk of data programmed,
so we can reuse the SVC buffer for the next chunk.
Tested on Terasic DE10 Pro.
Sponsored by: UKRI
On some platforms this static information can be derived directly from
the CPU, and there doesn't seem much use in restricting it.
Reviewed by: emaste, imp, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43281
Prompted by Phabricator's complaint that a C source file was a binary
file, in D43192.
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D43229
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
After removing filter functionality, the naming doesn't clearly
represent what the function does, so try to address this. Include some
code clarity and style improvements.
Create a common version in subr_busdma_bounce.c, used by most
implementations. powerpc still needs its own version of the function,
due to its dmat->iommu == NULL check.
No functional change intended.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42896
Without filter functions, we do not need to keep track of tag ancestry.
All inheritance of the parent tag's parameters occurs when creating the
new child tag.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42895
Address filter functions are unused, unsupported, and now rejected.
Simplify some busdma code by removing filter functionality completely.
Note that the chains of parent tags become useless, and will be cleaned
up in the next commit.
No functional change intended.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42894
