Re: [OS-BUILD PATCH] [redhat] New configs in arch/arm64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2020-10-31 at 06:25 +0000, GitLab Bridge on behalf of jeremycline wrote:
> From: Fedora Kernel Team <kernel-team@xxxxxxxxxxxxxxxxx>
> 
> Hi,
> 
> As part of the ongoing rebase effort, the following configuration
> options need to be reviewed.
> 
> As a reminder, the ARK configuration flow involves moving unreviewed
> configuration options from the pending directory to the ark directory.
> In the diff below, options are removed from the pending directory and
> added to the ark hierarchy. The final options that need to be ACKed
> are the files that are being added to the ark hierarchy.
> 
> If the value for a file that is added should be changed, please reply
> with a better option.
> 
>  CONFIG_ARM64_ERRATUM_1508412:
> 
>  This option adds a workaround for Arm Cortex-A77 erratum 1508412.
> 
>  Affected Cortex-A77 cores (r0p0, r1p0) could deadlock on a sequence
>  of a store-exclusive or read of PAR_EL1 and a load with device or
>  non-cacheable memory attributes. The workaround depends on a firmware
>  counterpart.
> 
>  KVM guests must also have the workaround implemented or they can
>  deadlock the system.
> 
>  Work around the issue by inserting DMB SY barriers around PAR_EL1
>  register reads and warning KVM users. The DMB barrier is sufficient
>  to prevent a speculative PAR_EL1 read.
> 
>  If unsure, say Y.
> 
>  Symbol: ARM64_ERRATUM_1508412 [=y]
>  Type  : bool
>  Defined at arch/arm64/Kconfig:639
>    Prompt: Cortex-A77: 1508412: workaround deadlock on sequence of NC/Device load and store exclusive or PAR read
>    Location:
>      -> Kernel Features
>        -> ARM errata workarounds via the alternatives framework
> 
> ---
> 
> Cc: Mark Salter <msalter@xxxxxxxxxx>
> Signed-off-by: Fedora Kernel Team <kernel-team@xxxxxxxxxxxxxxxxx>
> ---
>  .../generic/CONFIG_ARM64_ERRATUM_1508412      |  1 +
>  .../generic/CONFIG_ARM64_ERRATUM_1508412      | 29 -------------------
>  2 files changed, 1 insertion(+), 29 deletions(-)
>  create mode 100644 redhat/configs/common/generic/CONFIG_ARM64_ERRATUM_1508412
>  delete mode 100644 redhat/configs/pending-common/generic/CONFIG_ARM64_ERRATUM_1508412
> 
> diff --git a/redhat/configs/common/generic/CONFIG_ARM64_ERRATUM_1508412 b/redhat/configs/common/generic/CONFIG_ARM64_ERRATUM_1508412
> new file mode 100644
> index 000000000000..241640b0fee7
> --- /dev/null
> +++ b/redhat/configs/common/generic/CONFIG_ARM64_ERRATUM_1508412
> @@ -0,0 +1 @@
> +CONFIG_ARM64_ERRATUM_1508412=y

This belongs in redhat/configs/common/generic/arm/aarch64

> diff --git a/redhat/configs/pending-common/generic/CONFIG_ARM64_ERRATUM_1508412 b/redhat/configs/pending-common/generic/CONFIG_ARM64_ERRATUM_1508412
> deleted file mode 100644
> index 749f590b1c0d..000000000000
> --- a/redhat/configs/pending-common/generic/CONFIG_ARM64_ERRATUM_1508412
> +++ /dev/null
> @@ -1,29 +0,0 @@
> -# CONFIG_ARM64_ERRATUM_1508412:
> -# 
> -# This option adds a workaround for Arm Cortex-A77 erratum 1508412.
> -# 
> -# Affected Cortex-A77 cores (r0p0, r1p0) could deadlock on a sequence
> -# of a store-exclusive or read of PAR_EL1 and a load with device or
> -# non-cacheable memory attributes. The workaround depends on a firmware
> -# counterpart.
> -# 
> -# KVM guests must also have the workaround implemented or they can
> -# deadlock the system.
> -# 
> -# Work around the issue by inserting DMB SY barriers around PAR_EL1
> -# register reads and warning KVM users. The DMB barrier is sufficient
> -# to prevent a speculative PAR_EL1 read.
> -# 
> -# If unsure, say Y.
> -# 
> -# Symbol: ARM64_ERRATUM_1508412 [=y]
> -# Type  : bool
> -# Defined at arch/arm64/Kconfig:639
> -#   Prompt: Cortex-A77: 1508412: workaround deadlock on sequence of NC/Device load and store exclusive or PAR read
> -#   Location:
> -#     -> Kernel Features
> -#       -> ARM errata workarounds via the alternatives framework
> -# 
> -# 
> -# 
> -CONFIG_ARM64_ERRATUM_1508412=y
> -- 
> GitLab
> _______________________________________________
> kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx

_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux