arm64: Read the CPU feature tunables once

Rather than reading the CPU tunables each time we enable a feature
just read them once on boot. Reading them early on non-boot CPUs
causes issues where they

arm64: Read the CPU feature tunables once

Rather than reading the CPU tunables each time we enable a feature
just read them once on boot. Reading them early on non-boot CPUs
causes issues where they try to allocate memory before the core is set
up to do so. As they don't change it is safe to cache the state of
them.

Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D52578

show more ...

arm64: Add cpu_feat_disabled for disabled features

When a feature is disabled we may need to run a cleanup handler, e.g.
to remove a feature from the sanitized ID registers. Add support for
this wit

arm64: Add cpu_feat_disabled for disabled features

When a feature is disabled we may need to run a cleanup handler, e.g.
to remove a feature from the sanitized ID registers. Add support for
this with a new feat_disabled handler.

Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D52577

show more ...

arm64: Support managing features from loader

Allow the user to enable/disable supported cpu features/errata from a
known tunable. This will allow the user to disable features, e.g. to
work around br

arm64: Support managing features from loader

Allow the user to enable/disable supported cpu features/errata from a
known tunable. This will allow the user to disable features, e.g. to
work around broken firmware. It can also be used to enable workarounds
for rare errata.

Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D52358

show more ...

arm64: Add a sysctl to see if features are enabled

This will also be used as a tunable to control features in a later
change.

Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://r

arm64: Add a sysctl to see if features are enabled

This will also be used as a tunable to control features in a later
change.

Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D52357

show more ...

arm64: Add a macro to create cpu_feat

This will be used later to extend cpu feature detection

Reviewed by: imp (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freeb

arm64: Add a macro to create cpu_feat

This will be used later to extend cpu feature detection

Reviewed by: imp (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D52356

show more ...

arm64: Add a new CPU feature framework

This will be used to enable features that are discoverable on boot. It
has support to check if a feature needs to be enabled, and if there is
any errata associ

arm64: Add a new CPU feature framework

This will be used to enable features that are discoverable on boot. It
has support to check if a feature needs to be enabled, and if there is
any errata associated with the feature that mean it shouldn't be
enabled. It can also be used to enable errata workarounds that aren't
associated with a specific feature, e.g. where we need to trap access
to a register in userspace to emulate it.

As some features need to be enabled early, while others can wait there
are two options for when to enable a feature:
* CPU_FEAT_EARLY_BOOT: The feature will be enabled early in the boot.
On the boot CPU this is in initarm, while on secondary CPUs this
is before signalling the CPU has started.
* CPU_FEAT_AFTER_DEV: The feature will be enabled after devices have
attached but before interrupts are enabled.

There are also two scopes for where to enable the feature:
* CPU_FEAT_PER_CPU: The feature will be checked and enabled on all
CPU cores.
* CPU_FEAT_SYSTEM: The feature will only be checked and enabled on a
single core.
It is expected the former will be used for most features, while the
latter is for features that set a global variable to be checked.

Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47812

show more ...

arm64: Read the CPU feature tunables once

Rather than reading the CPU tunables each time we enable a feature
just read them once on boot. Reading them early on non-boot CPUs
causes issues where they

arm64: Read the CPU feature tunables once

Rather than reading the CPU tunables each time we enable a feature
just read them once on boot. Reading them early on non-boot CPUs
causes issues where they try to allocate memory before the core is set
up to do so. As they don't change it is safe to cache the state of
them.

Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D52578

show more ...

arm64: Add cpu_feat_disabled for disabled features

When a feature is disabled we may need to run a cleanup handler, e.g.
to remove a feature from the sanitized ID registers. Add support for
this wit

arm64: Add cpu_feat_disabled for disabled features

When a feature is disabled we may need to run a cleanup handler, e.g.
to remove a feature from the sanitized ID registers. Add support for
this with a new feat_disabled handler.

Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D52577

show more ...

arm64: Support managing features from loader

Allow the user to enable/disable supported cpu features/errata from a
known tunable. This will allow the user to disable features, e.g. to
work around br

arm64: Support managing features from loader

Allow the user to enable/disable supported cpu features/errata from a
known tunable. This will allow the user to disable features, e.g. to
work around broken firmware. It can also be used to enable workarounds
for rare errata.

Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D52358

show more ...

arm64: Add a sysctl to see if features are enabled

This will also be used as a tunable to control features in a later
change.

Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://r

arm64: Add a sysctl to see if features are enabled

This will also be used as a tunable to control features in a later
change.

Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D52357

show more ...

arm64: Add a macro to create cpu_feat

This will be used later to extend cpu feature detection

Reviewed by: imp (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freeb

arm64: Add a macro to create cpu_feat

This will be used later to extend cpu feature detection

Reviewed by: imp (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D52356

show more ...

arm64: Add a new CPU feature framework

This will be used to enable features that are discoverable on boot. It
has support to check if a feature needs to be enabled, and if there is
any errata associ

arm64: Add a new CPU feature framework

This will be used to enable features that are discoverable on boot. It
has support to check if a feature needs to be enabled, and if there is
any errata associated with the feature that mean it shouldn't be
enabled. It can also be used to enable errata workarounds that aren't
associated with a specific feature, e.g. where we need to trap access
to a register in userspace to emulate it.

As some features need to be enabled early, while others can wait there
are two options for when to enable a feature:
* CPU_FEAT_EARLY_BOOT: The feature will be enabled early in the boot.
On the boot CPU this is in initarm, while on secondary CPUs this
is before signalling the CPU has started.
* CPU_FEAT_AFTER_DEV: The feature will be enabled after devices have
attached but before interrupts are enabled.

There are also two scopes for where to enable the feature:
* CPU_FEAT_PER_CPU: The feature will be checked and enabled on all
CPU cores.
* CPU_FEAT_SYSTEM: The feature will only be checked and enabled on a
single core.
It is expected the former will be used for most features, while the
latter is for features that set a global variable to be checked.

Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47812

show more ...

arm64: Read the CPU feature tunables once

Rather than reading the CPU tunables each time we enable a feature
just read them once on boot. Reading them early on non-boot CPUs
causes issues where they

arm64: Read the CPU feature tunables once

Rather than reading the CPU tunables each time we enable a feature
just read them once on boot. Reading them early on non-boot CPUs
causes issues where they try to allocate memory before the core is set
up to do so. As they don't change it is safe to cache the state of
them.

Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D52578

show more ...

arm64: Add cpu_feat_disabled for disabled features

When a feature is disabled we may need to run a cleanup handler, e.g.
to remove a feature from the sanitized ID registers. Add support for
this wit

arm64: Add cpu_feat_disabled for disabled features

When a feature is disabled we may need to run a cleanup handler, e.g.
to remove a feature from the sanitized ID registers. Add support for
this with a new feat_disabled handler.

Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D52577

show more ...

arm64: Support managing features from loader

Allow the user to enable/disable supported cpu features/errata from a
known tunable. This will allow the user to disable features, e.g. to
work around br

arm64: Support managing features from loader

Allow the user to enable/disable supported cpu features/errata from a
known tunable. This will allow the user to disable features, e.g. to
work around broken firmware. It can also be used to enable workarounds
for rare errata.

Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D52358

show more ...

arm64: Add a sysctl to see if features are enabled

This will also be used as a tunable to control features in a later
change.

Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://r

arm64: Add a sysctl to see if features are enabled

This will also be used as a tunable to control features in a later
change.

Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D52357

show more ...

arm64: Add a macro to create cpu_feat

This will be used later to extend cpu feature detection

Reviewed by: imp (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freeb

arm64: Add a macro to create cpu_feat

This will be used later to extend cpu feature detection

Reviewed by: imp (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D52356

show more ...

arm64: Add a new CPU feature framework

This will be used to enable features that are discoverable on boot. It
has support to check if a feature needs to be enabled, and if there is
any errata associ

arm64: Add a new CPU feature framework

This will be used to enable features that are discoverable on boot. It
has support to check if a feature needs to be enabled, and if there is
any errata associated with the feature that mean it shouldn't be
enabled. It can also be used to enable errata workarounds that aren't
associated with a specific feature, e.g. where we need to trap access
to a register in userspace to emulate it.

As some features need to be enabled early, while others can wait there
are two options for when to enable a feature:
* CPU_FEAT_EARLY_BOOT: The feature will be enabled early in the boot.
On the boot CPU this is in initarm, while on secondary CPUs this
is before signalling the CPU has started.
* CPU_FEAT_AFTER_DEV: The feature will be enabled after devices have
attached but before interrupts are enabled.

There are also two scopes for where to enable the feature:
* CPU_FEAT_PER_CPU: The feature will be checked and enabled on all
CPU cores.
* CPU_FEAT_SYSTEM: The feature will only be checked and enabled on a
single core.
It is expected the former will be used for most features, while the
latter is for features that set a global variable to be checked.

Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47812

show more ...