#
3e00c11a |
| 12-Jul-2024 |
Alan Cox <alc@FreeBSD.org> |
arm64: Support the L3 ATTR_CONTIGUOUS page size in pagesizes[]
Update pagesizes[] to include the L3 ATTR_CONTIGUOUS (L3C) page size, which is 64KB when the base page size is 4KB and 2MB when the bas
arm64: Support the L3 ATTR_CONTIGUOUS page size in pagesizes[]
Update pagesizes[] to include the L3 ATTR_CONTIGUOUS (L3C) page size, which is 64KB when the base page size is 4KB and 2MB when the base page size is 16KB.
Add support for L3C pages to shm_create_largepage().
Add support for creating L3C page mappings to pmap_enter(psind=1).
Add support for reporting L3C page mappings to mincore(2) and procstat(8).
Update vm_fault_soft_fast() and vm_fault_populate() to handle multiple superpage sizes.
Declare arm64 as supporting two superpage reservation sizes, and simulate two superpage reservation sizes, updating the vm_page's psind field to reflect the correct page size from pagesizes[]. (The next patch in this series will replace this simulation. This patch is already big enough.)
Co-authored-by: Eliot Solomon <ehs3@rice.edu> Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D45766
show more ...
|
#
4441dd40 |
| 15-Jun-2024 |
Mark Johnston <markj@FreeBSD.org> |
vm_phys: Fix a typo
Fixes: b16b4c22d2d1 ("vm_page: Implement lazy page initialization") Reported by: Steffen Nurpmeso <steffen@sdaoden.eu>
|
#
b16b4c22 |
| 14-Jun-2024 |
Mark Johnston <markj@FreeBSD.org> |
vm_page: Implement lazy page initialization
FreeBSD's boot times have decreased to the point where vm_page array initialization represents a significant fraction of the total boot time. For example,
vm_page: Implement lazy page initialization
FreeBSD's boot times have decreased to the point where vm_page array initialization represents a significant fraction of the total boot time. For example, when booting FreeBSD in Firecracker (a VMM designed to support lightweight VMs) with 128MB and 1GB of RAM, vm_page initialization consumes 9% (3ms) and 37% (21.5ms) of the kernel boot time, respectively. This is generally relevant in cloud environments, where one wants to be able to spin up VMs as quickly as possible.
This patch implements lazy initialization of (most) page structures, following a suggestion from cperciva@. The idea is to introduce a new free pool, VM_FREEPOOL_LAZYINIT, into which all vm_page structures are initially placed. For this to work, we need only initialize the first free page of each chunk placed into the buddy allocator. Then, early page allocations draw from the lazy init pool and initialize vm_page chunks (up to 16MB, 4096 pages) on demand. Once APs are started, an idle-priority thread drains the lazy init pool in the background to avoid introducing extra latency in the allocator. With this scheme, almost all of the initialization work is moved out of the critical path.
A couple of vm_phys operations require the pool to be drained before they can run: vm_phys_find_range() and vm_phys_unfree_page(). However, these are rare operations. I believe that vm_phys_find_freelist_contig() does not require any special treatment, as it only ever accesses the first page in a power-of-2-sized free page chunk, which is always initialized.
For now the new pool is only used on amd64 and arm64, since that's where I can easily test and those platforms would get the most benefit.
Reviewed by: alc, kib Differential Revision: https://reviews.freebsd.org/D40403
show more ...
|
Revision tags: release/14.1.0 |
|
#
0a44b8a5 |
| 03-May-2024 |
Bojan Novković <bnovkov@FreeBSD.org> |
vm: Simplify startup page dumping conditional
This commit introduces the MINIDUMP_STARTUP_PAGE_TRACKING symbol and uses it to simplify several instances of a complex preprocessor conditional for add
vm: Simplify startup page dumping conditional
This commit introduces the MINIDUMP_STARTUP_PAGE_TRACKING symbol and uses it to simplify several instances of a complex preprocessor conditional for adding pages allocated when bootstraping the kernel to minidumps.
Reviewed by: markj, mhorne Approved by: markj (mentor) Differential Revision: https://reviews.freebsd.org/D45085
show more ...
|
#
da76d349 |
| 03-May-2024 |
Bojan Novković <bnovkov@FreeBSD.org> |
uma: Deduplicate uma_small_alloc
This commit refactors the UMA small alloc code and removes most UMA machine-dependent code. The existing machine-dependent uma_small_alloc code is almost identical a
uma: Deduplicate uma_small_alloc
This commit refactors the UMA small alloc code and removes most UMA machine-dependent code. The existing machine-dependent uma_small_alloc code is almost identical across all architectures, except for powerpc where using the direct map addresses involved extra steps in some cases.
The MI/MD split was replaced by a default uma_small_alloc implementation that can be overridden by architecture-specific code by defining the UMA_MD_SMALL_ALLOC symbol. Furthermore, UMA_USE_DMAP was introduced to replace most UMA_MD_SMALL_ALLOC uses.
Reviewed by: markj, kib Approved by: markj (mentor) Differential Revision: https://reviews.freebsd.org/D45084
show more ...
|
#
1d3c2367 |
| 24-May-2024 |
Mitchell Horne <mhorne@FreeBSD.org> |
arm64, riscv: remove unused declaration
It is inherited from arm, where the global exists and is used. No functional change.
Reviewed by: markj MFC after: 3 days Sponsored by: The FreeBSD Foundatio
arm64, riscv: remove unused declaration
It is inherited from arm, where the global exists and is used. No functional change.
Reviewed by: markj MFC after: 3 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D45323
show more ...
|
#
9d40492e |
| 08-Apr-2024 |
Andrew Turner <andrew@FreeBSD.org> |
arm64: Check DMAP address is valid in PHYS_IN_DMAP
When checking if a physical address is in the DMAP region we assume all physical addresses between DMAP_MIN_PHYSADDR and DMAP_MAX_PHYSADDR are able
arm64: Check DMAP address is valid in PHYS_IN_DMAP
When checking if a physical address is in the DMAP region we assume all physical addresses between DMAP_MIN_PHYSADDR and DMAP_MAX_PHYSADDR are able to be accesses through the DMAP. It may be the case that there is device memory in this range that shouldn't be accessed through the DMAP mappings.
Add a check to PHYS_IN_DMAP that the translated virtual address is a valid kernel address. To support code that already checks the address is valid add PHYS_IN_DMAP_RANGE.
PR: 278233 Reviewed by: alc, markj Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D44677
show more ...
|
Revision tags: release/13.3.0 |
|
#
9fabf976 |
| 18-Nov-2023 |
Eliot Solomon <ehs3@rice.edu> |
arm64: fix free queue and reservation configuration for 16KB pages
Correctly configure the free page queues and the reservation size when the base page size is 16KB. In particular, the reservation
arm64: fix free queue and reservation configuration for 16KB pages
Correctly configure the free page queues and the reservation size when the base page size is 16KB. In particular, the reservation size was less than the L2 Block size, making L2 promotions and mappings all but impossible.
Reviewed by: markj Tested by: gallatin Differential Revision: https://reviews.freebsd.org/D42737
show more ...
|
#
52bf6257 |
| 08-Feb-2024 |
Mark Johnston <markj@FreeBSD.org> |
arm64: Define shadow maps for KMSAN
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 Revisio
arm64: Define shadow maps for KMSAN
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
show more ...
|
#
48d5dab7 |
| 25-Jan-2024 |
Mark Johnston <markj@FreeBSD.org> |
arm64: Add a VM_FREELIST_DMA32 freelist
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. Th
arm64: Add a VM_FREELIST_DMA32 freelist
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
show more ...
|
#
29363fb4 |
| 23-Nov-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove ancient SCCS tags.
Remove ancient SCCS tags from the tree, automated scripting, with two minor fixup to keep things compiling. All the common forms in the tree were removed with a perl s
sys: Remove ancient SCCS tags.
Remove ancient SCCS tags from the tree, automated scripting, with two minor fixup to keep things compiling. All the common forms in the tree were removed with a perl script.
Sponsored by: Netflix
show more ...
|
Revision tags: release/14.0.0 |
|
#
2ff63af9 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .h pattern
Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/
|
#
d5d97bed |
| 26-Jul-2023 |
Mike Karels <karels@FreeBSD.org> |
arm64 lib32: prepare arm64 headers to redirect to arm
In order to compile lib32 libraries and other 32-bit code on arm64, <machine/foo.h> needs to be redirected to an arm header rather than arm64 wh
arm64 lib32: prepare arm64 headers to redirect to arm
In order to compile lib32 libraries and other 32-bit code on arm64, <machine/foo.h> needs to be redirected to an arm header rather than arm64 when building with -m32. Ifdef the arm64 headers that are installed in /usr/include/machine and used by user-level software (including references from /usr/include/*.h) so that if __arm__ is defined when including the arm64 version, <arm/foo.h> is included rather than using the rest of the file's contents. Some arm headers had no arm64 equivalent; headers were added just to do the redirection. These files use #error if __arm__ is not defined to guard against confusion. Also add an include/arm Makefile, and modify Makefiles as needed to install everything, including the arm files in /usr/include/arm. fenv.h comes from lib/msun/arm/fenv.h.
The new arm64 headers are: acle-compat.h cpuinfo.h sysreg.h
Reviewed by: jrtc27, imp Differential Revision: https://reviews.freebsd.org/D40944
show more ...
|
#
e59d2023 |
| 28-Jun-2023 |
Alan Cox <alc@FreeBSD.org> |
arm64: make VM_NFREEORDER and the comment describing it match
The setting of VM_NFREEORDER and the comment describing it were copied from sparc64 where both the page size and the number of page tabl
arm64: make VM_NFREEORDER and the comment describing it match
The setting of VM_NFREEORDER and the comment describing it were copied from sparc64 where both the page size and the number of page table entries that fit in a cache line are different from arm64.
Reviewed by: andrew, kib, markj MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D40782
show more ...
|
Revision tags: release/13.2.0 |
|
#
89c52f9d |
| 23-Mar-2023 |
Kyle Evans <kevans@FreeBSD.org> |
arm64: add KASAN support
This entails: - Marking some obvious candidates for __nosanitizeaddress - Similar trap frame markings as amd64, for similar reasons - Shadow map implementation
The shadow m
arm64: add KASAN support
This entails: - Marking some obvious candidates for __nosanitizeaddress - Similar trap frame markings as amd64, for similar reasons - Shadow map implementation
The shadow map implementation is roughly similar to what was done on amd64, with some exceptions. Attempting to use available space at preinit_map_va + PMAP_PREINIT_MAPPING_SIZE (up to the end of that range, as depicted in the physmap) results in odd failures, so we instead search the physmap for free regions that we can carve out, fragmenting the shadow map as necessary to try and fit as much as we need for the initial kernel map. pmap_bootstrap_san() is thus after pmap_bootstrap(), which still included some technically reserved areas of the memory map that needed to be included in the DMAP.
The odd failure noted above may be a bug, but I haven't investigated it all that much.
Initial work by mhorne with additional fixes from kevans and markj.
Reviewed by: andrew, markj Sponsored by: Juniper Networks, Inc. Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D36701
show more ...
|
Revision tags: release/12.4.0, release/13.1.0 |
|
#
a19acfd5 |
| 10-Mar-2022 |
Andrew Turner <andrew@FreeBSD.org> |
Fix the arm64 DMAP start address in a comment
Sponsored by: The FreeBSD Foundation
|
Revision tags: release/12.3.0 |
|
#
6713be31 |
| 30-Aug-2021 |
Andrew Turner <andrew@FreeBSD.org> |
Add NT_ARM_ADDR_MASK
This can be used by debuggers to find which bits in a virtual address should be masked off to get a canonical address. This is currently used by the Pointer Authentication Code
Add NT_ARM_ADDR_MASK
This can be used by debuggers to find which bits in a virtual address should be masked off to get a canonical address. This is currently used by the Pointer Authentication Code support to get its mask. It could also be used if we support Top Byte Ignore for the same purpose.
Reviewed by: kib Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D34302
show more ...
|
#
85b7c566 |
| 08-Jul-2021 |
Andrew Turner <andrew@FreeBSD.org> |
Add arm64 pointer authentication support
Pointer authentication allows userspace to add instructions to insert a Pointer Authentication Code (PAC) into a register based on an address and modifier an
Add arm64 pointer authentication support
Pointer authentication allows userspace to add instructions to insert a Pointer Authentication Code (PAC) into a register based on an address and modifier and check if the PAC is correct. If the check fails it will either return an invalid address or fault to the kernel.
As many of these instructions are a NOP when disabled and in earlier revisions of the architecture this can be used, for example, to sign the return address before pushing it to the stack making Return-oriented programming (ROP) attack more difficult on hardware that supports them.
The kernel manages five 128 bit signing keys: 2 instruction keys, 2 data keys, and a generic key. The instructions then use one of these when signing the registers. Instructions that use the first four store the PAC in the register being signed, however the instructions that use the generic key store the PAC in a separate register.
Currently all userspace threads share all the keys within a process with a new set of userspace keys being generated when executing a new process. This means a forked child will share its keys with its parent until it calls an appropriate exec system call.
In the kernel we allow the use of one of the instruction keys, the ia key. This will be used to sign return addresses in function calls. Unlike userspace each kernel thread has its own randomly generated.
Thread0 has a static key as does the early code on secondary CPUs. This should be safe as there is minimal user interaction with these threads, however we could generate random keys when the Armv8.5 Random number generation instructions are present.
Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D31261
show more ...
|
#
b7a78d57 |
| 14-Jul-2021 |
Andrew Turner <andrew@FreeBSD.org> |
Start to clean up arm64 address space selection
On arm64 we should use bit 55 of the address to decide if aan address is a user or kernel address. Add a new macro with this check and a second to ens
Start to clean up arm64 address space selection
On arm64 we should use bit 55 of the address to decide if aan address is a user or kernel address. Add a new macro with this check and a second to ensure the address is in teh canonical form, i.e. the top bits are all zero or all one.
This will help with supporting future cpu features, including Top Byte Ignore, Pointer Authentication, and Memory Tagging.
Reviewed by: kib Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D31179
show more ...
|
#
e779604f |
| 20-May-2021 |
Andrew Turner <andrew@FreeBSD.org> |
Clean up early arm64 pmap code
Early in the arm64 pmap code we need to translate between a virtual address and a physical address. Rather than manually walking the page table we can ask the hardware
Clean up early arm64 pmap code
Early in the arm64 pmap code we need to translate between a virtual address and a physical address. Rather than manually walking the page table we can ask the hardware to do it for us.
Reviewed by: kib, markj Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D30357
show more ...
|
Revision tags: release/13.0.0 |
|
#
3e3eb5f4 |
| 20-Jan-2021 |
Mark Johnston <markj@FreeBSD.org> |
arm64, riscv: Set VM_KMEM_SIZE_SCALE to 1
This setting limits the amount of memory that can be allocated to UMA. On systems with a direct map and ample KVA, however, there is no reason for VM_KMEM_S
arm64, riscv: Set VM_KMEM_SIZE_SCALE to 1
This setting limits the amount of memory that can be allocated to UMA. On systems with a direct map and ample KVA, however, there is no reason for VM_KMEM_SIZE_SCALE to be larger than 1. This appears to have been inherited from the 32-bit ARM platform definitions.
Also remove VM_KMEM_SIZE_MIN, which is not needed when VM_KMEM_SIZE_SCALE is defined to be 1.[*]
Reviewed by: alc, kp, kib Reported by: alc [*] Submitted by: Klara, Inc. Sponsored by: Ampere Computing Differential Revision: https://reviews.freebsd.org/D28225
show more ...
|
Revision tags: release/12.2.0 |
|
#
78257765 |
| 23-Sep-2020 |
Mark Johnston <markj@FreeBSD.org> |
Add a vmparam.h constant indicating pmap support for large pages.
Enable SHM_LARGEPAGE support on arm64.
Reviewed by: alc, kib Sponsored by: Juniper Networks, Inc., Klara, Inc. Differential Revisio
Add a vmparam.h constant indicating pmap support for large pages.
Enable SHM_LARGEPAGE support on arm64.
Reviewed by: alc, kib Sponsored by: Juniper Networks, Inc., Klara, Inc. Differential Revision: https://reviews.freebsd.org/D26467
show more ...
|
#
ab041f71 |
| 22-Sep-2020 |
D Scott Phillips <scottph@FreeBSD.org> |
Move vm_page_dump bitset array definition to MI code
These definitions were repeated by all architectures, with small variations. Consolidate the common definitons in machine independent code and us
Move vm_page_dump bitset array definition to MI code
These definitions were repeated by all architectures, with small variations. Consolidate the common definitons in machine independent code and use bitset(9) macros for manipulation. Many opportunities for deduplication remain in the machine dependent minidump logic. The only intended functional change is increasing the bit index type to vm_pindex_t, allowing the indexing of pages with address of 8 TiB and greater.
Reviewed by: kib, markj Approved by: scottl (implicit) MFC after: 1 week Sponsored by: Ampere Computing, Inc. Differential Revision: https://reviews.freebsd.org/D26129
show more ...
|
#
e2515283 |
| 27-Aug-2020 |
Glen Barber <gjb@FreeBSD.org> |
MFH
Sponsored by: Rubicon Communications, LLC (netgate.com)
|
#
d4d2928a |
| 26-Aug-2020 |
D Scott Phillips <scottph@FreeBSD.org> |
arm64: Increase dmap size to 95 TiB
The Ampere Altra has physical memory populated sparsely within the physical address space. Increase the size of the dmap to cover all physical memory.
Reviewed b
arm64: Increase dmap size to 95 TiB
The Ampere Altra has physical memory populated sparsely within the physical address space. Increase the size of the dmap to cover all physical memory.
Reviewed by: andrew Approved by: scottl (implicit) MFC after: 1 week Sponsored by: Ampere Computing, Inc. Differential Revision: https://reviews.freebsd.org/D26134
show more ...
|