History log of /freebsd/sys/arm64/include/pcpu.h (Results 1 – 25 of 36)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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


12