#
d5aead83 |
| 27-Mar-2024 |
Jessica Clarke <jrtc27@FreeBSD.org> |
arm64: Delete stale comment
Fixes: 078a69abcbb8 ("Use a uint64_t to store the arm64 mpidr")
|
Revision tags: release/13.3.0, 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/
|
#
1083a8cd |
| 24-Jul-2023 |
Mark Johnston <markj@FreeBSD.org> |
pcpu: Remove unused definitions of ALT_STACK_SIZE
This was added originally for the sparc64 port and apparently copied to other platforms. No functional change intended.
MFC after: 1 week
|
#
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 ...
|
#
078a69ab |
| 24-Apr-2023 |
Andrew Turner <andrew@FreeBSD.org> |
Use a uint64_t to store the arm64 mpidr
Use a single uint64_t to hole the mpidr register as we can break the KBI on 14. Keep the macro so code can still be MFCd to 13.
Sponsored by: Arm Ltd
|
Revision tags: release/13.2.0, release/12.4.0 |
|
#
544f047f |
| 25-Aug-2022 |
Andrew Turner <andrew@FreeBSD.org> |
Store mpidr as a 64-bit value on arm64
The mpidr register is 64 bit on arm64 and 32 bit on arm. Fix this by extending the arm64 definition to include the top 32 bits.
To preserve KBI when MFCing sp
Store mpidr as a 64-bit value on arm64
The mpidr register is 64 bit on arm64 and 32 bit on arm. Fix this by extending the arm64 definition to include the top 32 bits.
To preserve KBI when MFCing split the value into two 32 bit values. This will be cleaned up later only on main.
Reviewed by: bz Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D36346
show more ...
|
Revision tags: release/13.1.0 |
|
#
ed306634 |
| 08-Mar-2022 |
Andrew Turner <andrew@FreeBSD.org> |
Make the arm64 get_pcpu a function again
We assume the pointer returned from get_pcpu will be consistent even if the thread is moved to a new CPU. Fix this by partially reverting 63c858a04d565 to ma
Make the arm64 get_pcpu a function again
We assume the pointer returned from get_pcpu will be consistent even if the thread is moved to a new CPU. Fix this by partially reverting 63c858a04d565 to make get_pcpu a function again.
Sponsored by: The FreeBSD Foundation
show more ...
|
Revision tags: release/12.3.0, release/13.0.0 |
|
#
d22883d7 |
| 10-Mar-2021 |
Jason A. Harmening <jah@FreeBSD.org> |
Remove PCPU_INC
e4b8deb22227 removed the last in-tree uses of PCPU_INC(). Its potential benefit is also practically nonexistent. Non-x86 platforms already implement it as PCPU_ADD(..., 1), and acc
Remove PCPU_INC
e4b8deb22227 removed the last in-tree uses of PCPU_INC(). Its potential benefit is also practically nonexistent. Non-x86 platforms already implement it as PCPU_ADD(..., 1), and according to [0] there are no recent x86 processors for which the 'inc' instruction provides a performance benefit over the equivalent memory-operand form of the 'add' instruction. The only remaining benefit of 'inc' is smaller instruction size, which in this case is inconsequential given the limited number of per-CPU data consumers.
[0]: https://www.agner.org/optimize/instruction_tables.pdf
Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D29308
show more ...
|
#
63c858a0 |
| 11-Jan-2021 |
Andrew Turner <andrew@FreeBSD.org> |
Switch the arm64 pcpu to a global register variable
This removes an unneeded instruction to move the pointer from x18 to a temporary register.
Reviewed by: emaste Sponsored by: Innovate UK Differen
Switch the arm64 pcpu to a global register variable
This removes an unneeded instruction to move the pointer from x18 to a temporary register.
Reviewed by: emaste Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D26971
show more ...
|
#
68225a19 |
| 05-Dec-2020 |
Michal Meloun <mmel@FreeBSD.org> |
Simplify startup of secondary cores and store MPIDR register to pcpu.
- record MPIDR for all started cores in pcpu, they will be used as link between physical locality of given core, ID in exter
Simplify startup of secondary cores and store MPIDR register to pcpu.
- record MPIDR for all started cores in pcpu, they will be used as link between physical locality of given core, ID in external description (FDT or ACPI) and cupid. - because of above, cpuid can (and should) be freely assigned, only boot CPU must have cpuid 0. Simplify startup code according this.
Please note that pure cpuid is not sufficient instrument to hold any information about core or cluster topology, nor to determistically iterate over subpart of cores in CPU (iterate over all cores in single cluster for example). Situation is more complicated by fact that PSCI can reject start of core without reporting error (because power budget for example), or by fact that is possible that we booted on non-first core in cluster (thus with cpuid 0 assigned to random core).
Given cores topology should be exhibited to other parts of system (for example to scheduler for big.little or multicluster systems) by using smp_topo interface.
Differential Revision: https://reviews.freebsd.org/D13863
show more ...
|
Revision tags: release/12.2.0, release/11.4.0 |
|
#
2cb0e95f |
| 27-May-2020 |
Andrew Turner <andrew@FreeBSD.org> |
Support creating and using arm64 pmap at stage 2
Add minimal support for creating stage 2 IPA -> PA mappings. For this we need to:
- Create a new vmid set to allocate a vmid for each Virtual Machi
Support creating and using arm64 pmap at stage 2
Add minimal support for creating stage 2 IPA -> PA mappings. For this we need to:
- Create a new vmid set to allocate a vmid for each Virtual Machine - Add the missing stage 2 attributes - Use these in pmap_enter to create a new mapping - Handle stage 2 faults
The vmid set is based on the current asid set that was generalised in r358328. It adds a function pointer for bhyve to use when the kernel needs to reset the vmid set. This will need to call into EL2 and invalidate the TLB.
The stage 2 attributes have been added. To simplify setting these fields two new functions are added to get the memory type and protection fields. These are slightly different on stage 1 and stage 2 tables. We then use them in pmap_enter to set the new level 3 entry to be stored.
The D-cache on all entries is cleaned to the point of coherency. This is to allow the data to be visible to the VM. To allow for userspace to load code when creating a new executable entry an invalid entry is created. When the VM tried to use it the I-cache is invalidated. As the D-cache has already been cleaned this will ensure the I-cache is synchronised with the D-cache.
When the hardware implements a VPIPT I-cache we need to either have the correct VMID set or invalidate it from EL2. As the host kernel will have the wrong VMID set we need to call into EL2 to clean it. For this a second function pointer is added that is called when this invalidation is needed.
Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D23875
show more ...
|
#
50e3ab6b |
| 03-Nov-2019 |
Alan Cox <alc@FreeBSD.org> |
Utilize ASIDs to reduce both the direct and indirect costs of context switching. The indirect costs being unnecessary TLB misses that are incurred when ASIDs are not used. In fact, currently, when
Utilize ASIDs to reduce both the direct and indirect costs of context switching. The indirect costs being unnecessary TLB misses that are incurred when ASIDs are not used. In fact, currently, when we perform a context switch on one processor, we issue a broadcast TLB invalidation that flushes the TLB contents on every processor.
Mark all user-space ("ttbr0") page table entries with the non-global flag so that they are cached in the TLB under their ASID.
Correct an error in pmap_pinit0(). The pointer to the root of the page table was being initialized to the root of the kernel-space page table rather than a user-space page table. However, the root of the page table that was being cached in process 0's md_l0addr field correctly pointed to a user-space page table. As long as ASIDs weren't being used, this was harmless, except that it led to some unnecessary page table switches in pmap_switch(). Specifically, other kernel processes besides process 0 would have their md_l0addr field set to the root of the kernel-space page table, and so pmap_switch() would actually change page tables when switching between process 0 and other kernel processes.
Implement a workaround for Cavium erratum 27456 affecting ThunderX machines. (I would like to thank andrew@ for providing the code to detect the affected machines.)
Address integer overflow in the definition of TCR_ASID_16.
Setup TCR according to the PARange and ASIDBits fields from ID_AA64MMFR0_EL1. Previously, TCR_ASID_16 was unconditionally set.
Modify build_l1_block_pagetable so that lower attributes, such as ATTR_nG, can be specified as a parameter.
Eliminate some unused code.
Earlier versions were tested to varying degrees by: andrew, emaste, markj
MFC after: 3 weeks Differential Revision: https://reviews.freebsd.org/D21922
show more ...
|
Revision tags: release/12.1.0 |
|
#
a5d295e2 |
| 30-Oct-2019 |
Andrew Turner <andrew@FreeBSD.org> |
Update the debug monitor handling to work after userspace has started
The debug monitor register state is now stored in a struct and updated when required. Currently there is only a kernel state, ho
Update the debug monitor handling to work after userspace has started
The debug monitor register state is now stored in a struct and updated when required. Currently there is only a kernel state, however a per-process state will be added in a future change.
Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D22128
show more ...
|
Revision tags: release/11.3.0, release/12.0.0 |
|
#
14b841d4 |
| 11-Aug-2018 |
Kyle Evans <kevans@FreeBSD.org> |
MFH @ r337607, in preparation for boarding
|
#
bbd7a929 |
| 04-Aug-2018 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r336870 through r337285, and resolve conflicts.
|
#
100a6d19 |
| 31-Jul-2018 |
Andrew Turner <andrew@FreeBSD.org> |
Use int for the pcpu_ssbd argument. This is included from userland and may not include the needed headers to get the bool definition.
Reported by: manu Pointy hat to: andrew Sponsored by: DARPA, AFRL
|
#
0594061e |
| 31-Jul-2018 |
Andrew Turner <andrew@FreeBSD.org> |
Implement the SSBD (CVE-2018-3639) workaround on arm64
This calls into the Arm Trusted Firmware to enable and disable the workaround for the Speculative Store Bypass Disable (SSBD) issue, also known
Implement the SSBD (CVE-2018-3639) workaround on arm64
This calls into the Arm Trusted Firmware to enable and disable the workaround for the Speculative Store Bypass Disable (SSBD) issue, also known as Spectre Variant 4.
As this may have a large performance overhead, and how exploitable SSBD is is unknown we follow the Linux lead of allowing the administrator to select between always on, always off, or only enabled in the kernel, with the latter being the default.
PR: 228955 Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D15819
show more ...
|
Revision tags: release/11.2.0 |
|
#
c79126f2 |
| 12-Jan-2018 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r327624 through r327885.
|
#
7023544a |
| 12-Jan-2018 |
Andrew Turner <andrew@FreeBSD.org> |
Workaround Spectre Variant 2 on arm64.
We need to handle two cases:
1. One process attacking another process. 2. A process attacking the kernel.
For the first case we clear the branch predictor st
Workaround Spectre Variant 2 on arm64.
We need to handle two cases:
1. One process attacking another process. 2. A process attacking the kernel.
For the first case we clear the branch predictor state on context switch between different processes. For the second we do this when taking an instruction abort on a non-userspace address.
To clear the branch predictor state a per-CPU function pointer has been added. This is set by the new cpu errata code based on if the CPU is known to be affected.
On Cortex-A57, A72, A73, and A75 we call into the PSCI firmware as newer versions of this will clear the branch predictor state for us.
It has been reported the ThunderX is unaffected, however the ThunderX2 is vulnerable. The Qualcomm Falkor core is also affected. As FreeBSD doesn't yet run on the ThunderX2 or Falkor no workaround is included for these CPUs.
MFC after: 3 days Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D13812
show more ...
|
Revision tags: release/10.4.0, release/11.1.0 |
|
#
554491ff |
| 20-Apr-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r316992 through r317215.
|
#
83c9dea1 |
| 17-Apr-2017 |
Gleb Smirnoff <glebius@FreeBSD.org> |
- Remove 'struct vmmeter' from 'struct pcpu', leaving only global vmmeter in place. To do per-cpu stats, convert all fields that previously were maintained in the vmmeters that sit in pcpus to c
- Remove 'struct vmmeter' from 'struct pcpu', leaving only global vmmeter in place. To do per-cpu stats, convert all fields that previously were maintained in the vmmeters that sit in pcpus to counter(9). - Since some vmmeter stats may be touched at very early stages of boot, before we have set up UMA and we can do counter_u64_alloc(), provide an early counter mechanism: o Leave one spare uint64_t in struct pcpu, named pc_early_dummy_counter. o Point counter(9) fields of vmmeter to pcpu[0].pc_early_dummy_counter, so that at early stages of boot, before counters are allocated we already point to a counter that can be safely written to. o For sparc64 that required a whole dummy pcpu[MAXCPU] array.
Further related changes: - Don't include vmmeter.h into pcpu.h. - vm.stats.vm.v_swappgsout and vm.stats.vm.v_swappgsin changed to 64-bit, to match kernel representation. - struct vmmeter hidden under _KERNEL, and only vmstat(1) is an exclusion.
This is based on benno@'s 4-year old patch: https://lists.freebsd.org/pipermail/freebsd-arch/2013-July/014471.html
Reviewed by: kib, gallatin, marius, lidl Differential Revision: https://reviews.freebsd.org/D10156
show more ...
|
Revision tags: release/11.0.1, release/11.0.0 |
|
#
637cce3a |
| 03-Sep-2016 |
Enji Cooper <ngie@FreeBSD.org> |
MFhead @ r305314
|
#
2aeb0380 |
| 02-Sep-2016 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r305220 through r305300.
|
#
af693689 |
| 02-Sep-2016 |
Andrew Turner <andrew@FreeBSD.org> |
Add a pc_clock pcpu field and use it to implement cpu_est_clockrate. This will allow drivers that manage the clock frequency to communicate this with the reset of the kernel.
Reported by: jmcneill M
Add a pc_clock pcpu field and use it to implement cpu_est_clockrate. This will allow drivers that manage the clock frequency to communicate this with the reset of the kernel.
Reported by: jmcneill MFC after: 1 week Sponsored by: ABT Systems Ltd
show more ...
|
Revision tags: release/10.3.0 |
|
#
b5ff185e |
| 12-Sep-2015 |
Baptiste Daroussin <bapt@FreeBSD.org> |
Merge from head
|