Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit ca78d317 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux 

Pull arm64 updates from Will Deacon:
 - Errata workarounds for Qualcomm's Falkor CPU
 - Qualcomm L2 Cache PMU driver
 - Qualcomm SMCCC firmware quirk
 - Support for DEBUG_VIRTUAL
 - CPU feature detection for userspace via MRS emulation
 - Preliminary work for the Statistical Profiling Extension
 - Misc cleanups and non-critical fixes

* tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (74 commits)
  arm64/kprobes: consistently handle MRS/MSR with XZR
  arm64: cpufeature: correctly handle MRS to XZR
  arm64: traps: correctly handle MRS/MSR with XZR
  arm64: ptrace: add XZR-safe regs accessors
  arm64: include asm/assembler.h in entry-ftrace.S
  arm64: fix warning about swapper_pg_dir overflow
  arm64: Work around Falkor erratum 1003
  arm64: head.S: Enable EL1 (host) access to SPE when entered at EL2
  arm64: arch_timer: document Hisilicon erratum 161010101
  arm64: use is_vmalloc_addr
  arm64: use linux/sizes.h for constants
  arm64: uaccess: consistently check object sizes
  perf: add qcom l2 cache perf events driver
  arm64: remove wrong CONFIG_PROC_SYSCTL ifdef
  ARM: smccc: Update HVC comment to describe new quirk parameter
  arm64: do not trace atomic operations
  ACPI/IORT: Fix the error return code in iort_add_smmu_platform_device()
  ACPI/IORT: Fix iort_node_get_id() mapping entries indexing
  arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA
  perf: xgene: Include module.h
  ...
parents a4ee7bac ffe7afd1

Documentation/arm64/cpu-feature-registers.txt

0 → 100644
+240 −0
Original line number Diff line number Diff line 
		ARM64 CPU Feature Registers

		===========================



Author: Suzuki K Poulose <suzuki.poulose@arm.com>





This file describes the ABI for exporting the AArch64 CPU ID/feature

registers to userspace. The availability of this ABI is advertised

via the HWCAP_CPUID in HWCAPs.



1. Motivation

---------------



The ARM architecture defines a set of feature registers, which describe

the capabilities of the CPU/system. Access to these system registers is

restricted from EL0 and there is no reliable way for an application to

extract this information to make better decisions at runtime. There is

limited information available to the application via HWCAPs, however

there are some issues with their usage.



 a) Any change to the HWCAPs requires an update to userspace (e.g libc)

    to detect the new changes, which can take a long time to appear in

    distributions. Exposing the registers allows applications to get the

    information without requiring updates to the toolchains.



 b) Access to HWCAPs is sometimes limited (e.g prior to libc, or

    when ld is initialised at startup time).



 c) HWCAPs cannot represent non-boolean information effectively. The

    architecture defines a canonical format for representing features

    in the ID registers; this is well defined and is capable of

    representing all valid architecture variations.





2. Requirements

-----------------



 a) Safety :

    Applications should be able to use the information provided by the

    infrastructure to run safely across the system. This has greater

    implications on a system with heterogeneous CPUs.

    The infrastructure exports a value that is safe across all the

    available CPU on the system.



    e.g, If at least one CPU doesn't implement CRC32 instructions, while

    others do, we should report that the CRC32 is not implemented.

    Otherwise an application could crash when scheduled on the CPU

    which doesn't support CRC32.



 b) Security :

    Applications should only be able to receive information that is

    relevant to the normal operation in userspace. Hence, some of the

    fields are masked out(i.e, made invisible) and their values are set to

    indicate the feature is 'not supported'. See Section 4 for the list

    of visible features. Also, the kernel may manipulate the fields

    based on what it supports. e.g, If FP is not supported by the

    kernel, the values could indicate that the FP is not available

    (even when the CPU provides it).



 c) Implementation Defined Features

    The infrastructure doesn't expose any register which is

    IMPLEMENTATION DEFINED as per ARMv8-A Architecture.



 d) CPU Identification :

    MIDR_EL1 is exposed to help identify the processor. On a

    heterogeneous system, this could be racy (just like getcpu()). The

    process could be migrated to another CPU by the time it uses the

    register value, unless the CPU affinity is set. Hence, there is no

    guarantee that the value reflects the processor that it is

    currently executing on. The REVIDR is not exposed due to this

    constraint, as REVIDR makes sense only in conjunction with the

    MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs

    at:



	/sys/devices/system/cpu/cpu$ID/regs/identification/

	                                              \- midr

	                                              \- revidr



3. Implementation

--------------------



The infrastructure is built on the emulation of the 'MRS' instruction.

Accessing a restricted system register from an application generates an

exception and ends up in SIGILL being delivered to the process.

The infrastructure hooks into the exception handler and emulates the

operation if the source belongs to the supported system register space.



The infrastructure emulates only the following system register space:

	Op0=3, Op1=0, CRn=0, CRm=0,4,5,6,7



(See Table C5-6 'System instruction encodings for non-Debug System

register accesses' in ARMv8 ARM DDI 0487A.h, for the list of

registers).



The following rules are applied to the value returned by the

infrastructure:



 a) The value of an 'IMPLEMENTATION DEFINED' field is set to 0.

 b) The value of a reserved field is populated with the reserved

    value as defined by the architecture.

 c) The value of a 'visible' field holds the system wide safe value

    for the particular feature (except for MIDR_EL1, see section 4).

 d) All other fields (i.e, invisible fields) are set to indicate

    the feature is missing (as defined by the architecture).



4. List of registers with visible features

-------------------------------------------



  1) ID_AA64ISAR0_EL1 - Instruction Set Attribute Register 0

     x--------------------------------------------------x

     | Name                         |  bits   | visible |

     |--------------------------------------------------|

     | RES0                         | [63-32] |    n    |

     |--------------------------------------------------|

     | RDM                          | [31-28] |    y    |

     |--------------------------------------------------|

     | ATOMICS                      | [23-20] |    y    |

     |--------------------------------------------------|

     | CRC32                        | [19-16] |    y    |

     |--------------------------------------------------|

     | SHA2                         | [15-12] |    y    |

     |--------------------------------------------------|

     | SHA1                         | [11-8]  |    y    |

     |--------------------------------------------------|

     | AES                          | [7-4]   |    y    |

     |--------------------------------------------------|

     | RES0                         | [3-0]   |    n    |

     x--------------------------------------------------x





  2) ID_AA64PFR0_EL1 - Processor Feature Register 0

     x--------------------------------------------------x

     | Name                         |  bits   | visible |

     |--------------------------------------------------|

     | RES0                         | [63-28] |    n    |

     |--------------------------------------------------|

     | GIC                          | [27-24] |    n    |

     |--------------------------------------------------|

     | AdvSIMD                      | [23-20] |    y    |

     |--------------------------------------------------|

     | FP                           | [19-16] |    y    |

     |--------------------------------------------------|

     | EL3                          | [15-12] |    n    |

     |--------------------------------------------------|

     | EL2                          | [11-8]  |    n    |

     |--------------------------------------------------|

     | EL1                          | [7-4]   |    n    |

     |--------------------------------------------------|

     | EL0                          | [3-0]   |    n    |

     x--------------------------------------------------x





  3) MIDR_EL1 - Main ID Register

     x--------------------------------------------------x

     | Name                         |  bits   | visible |

     |--------------------------------------------------|

     | Implementer                  | [31-24] |    y    |

     |--------------------------------------------------|

     | Variant                      | [23-20] |    y    |

     |--------------------------------------------------|

     | Architecture                 | [19-16] |    y    |

     |--------------------------------------------------|

     | PartNum                      | [15-4]  |    y    |

     |--------------------------------------------------|

     | Revision                     | [3-0]   |    y    |

     x--------------------------------------------------x



   NOTE: The 'visible' fields of MIDR_EL1 will contain the value

   as available on the CPU where it is fetched and is not a system

   wide safe value.



Appendix I: Example

---------------------------



/*

 * Sample program to demonstrate the MRS emulation ABI.

 *

 * Copyright (C) 2015-2016, ARM Ltd

 *

 * Author: Suzuki K Poulose <suzuki.poulose@arm.com>

 *

 * This program is free software; you can redistribute it and/or modify

 * it under the terms of the GNU General Public License version 2 as

 * published by the Free Software Foundation.

 *

 * This program is distributed in the hope that it will be useful,

 * but WITHOUT ANY WARRANTY; without even the implied warranty of

 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

 * GNU General Public License for more details.

 * This program is free software; you can redistribute it and/or modify

 * it under the terms of the GNU General Public License version 2 as

 * published by the Free Software Foundation.

 *

 * This program is distributed in the hope that it will be useful,

 * but WITHOUT ANY WARRANTY; without even the implied warranty of

 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

 * GNU General Public License for more details.

 */



#include <asm/hwcap.h>

#include <stdio.h>

#include <sys/auxv.h>



#define get_cpu_ftr(id) ({					\

		unsigned long __val;				\

		asm("mrs %0, "#id : "=r" (__val));		\

		printf("%-20s: 0x%016lx\n", #id, __val);	\

	})



int main(void)

{



	if (!(getauxval(AT_HWCAP) & HWCAP_CPUID)) {

		fputs("CPUID registers unavailable\n", stderr);

		return 1;

	}



	get_cpu_ftr(ID_AA64ISAR0_EL1);

	get_cpu_ftr(ID_AA64ISAR1_EL1);

	get_cpu_ftr(ID_AA64MMFR0_EL1);

	get_cpu_ftr(ID_AA64MMFR1_EL1);

	get_cpu_ftr(ID_AA64PFR0_EL1);

	get_cpu_ftr(ID_AA64PFR1_EL1);

	get_cpu_ftr(ID_AA64DFR0_EL1);

	get_cpu_ftr(ID_AA64DFR1_EL1);



	get_cpu_ftr(MIDR_EL1);

	get_cpu_ftr(MPIDR_EL1);

	get_cpu_ftr(REVIDR_EL1);



#if 0

	/* Unexposed register access causes SIGILL */

	get_cpu_ftr(ID_MMFR0_EL1);

#endif



	return 0;

}

Documentation/arm64/silicon-errata.txt

+26 −21
Original line number Diff line number Diff line
@@ -43,7 +43,7 @@ will be updated when new workarounds are committed and backported to 
stable kernels.



| Implementor    | Component       | Erratum ID      | Kconfig                     |

+----------------+-----------------+-----------------+-------------------------+

+----------------+-----------------+-----------------+-----------------------------+

| ARM            | Cortex-A53      | #826319         | ARM64_ERRATUM_826319        |

| ARM            | Cortex-A53      | #827319         | ARM64_ERRATUM_827319        |

| ARM            | Cortex-A53      | #824069         | ARM64_ERRATUM_824069        |
@@ -63,3 +63,8 @@ stable kernels. 
| Cavium         | ThunderX SMMUv2 | #27704          | N/A                         |

|                |                 |                 |                             |

| Freescale/NXP  | LS2080A/LS1043A | A-008585        | FSL_ERRATUM_A008585         |

|                |                 |                 |                             |

| Hisilicon      | Hip0{5,6,7}     | #161010101      | HISILICON_ERRATUM_161010101 |

|                |                 |                 |                             |

| Qualcomm Tech. | Falkor v1       | E1003           | QCOM_FALKOR_ERRATUM_1003    |

| Qualcomm Tech. | Falkor v1       | E1009           | QCOM_FALKOR_ERRATUM_1009    |

Documentation/perf/qcom_l2_pmu.txt

0 → 100644
+38 −0
Original line number Diff line number Diff line 
Qualcomm Technologies Level-2 Cache Performance Monitoring Unit (PMU)

=====================================================================



This driver supports the L2 cache clusters found in Qualcomm Technologies

Centriq SoCs. There are multiple physical L2 cache clusters, each with their

own PMU. Each cluster has one or more CPUs associated with it.



There is one logical L2 PMU exposed, which aggregates the results from

the physical PMUs.



The driver provides a description of its available events and configuration

options in sysfs, see /sys/devices/l2cache_0.



The "format" directory describes the format of the events.



Events can be envisioned as a 2-dimensional array. Each column represents

a group of events. There are 8 groups. Only one entry from each

group can be in use at a time. If multiple events from the same group

are specified, the conflicting events cannot be counted at the same time.



Events are specified as 0xCCG, where CC is 2 hex digits specifying

the code (array row) and G specifies the group (column) 0-7.



In addition there is a cycle counter event specified by the value 0xFE

which is outside the above scheme.



The driver provides a "cpumask" sysfs attribute which contains a mask

consisting of one CPU per cluster which will be used to handle all the PMU

events on that cluster.



Examples for use with perf:



  perf stat -e l2cache_0/config=0x001/,l2cache_0/config=0x042/ -a sleep 1



  perf stat -e l2cache_0/config=0xfe/ -C 2 sleep 1



The driver does not support sampling, therefore "perf record" will

not work. Per-task perf sessions are not supported.

arch/arm/kernel/armksyms.c

+2 −2
Original line number Diff line number Diff line
@@ -178,6 +178,6 @@ EXPORT_SYMBOL(__pv_offset); 
#endif



#ifdef CONFIG_HAVE_ARM_SMCCC

EXPORT_SYMBOL(arm_smccc_smc);

EXPORT_SYMBOL(arm_smccc_hvc);

EXPORT_SYMBOL(__arm_smccc_smc);

EXPORT_SYMBOL(__arm_smccc_hvc);

#endif

arch/arm/kernel/perf_event_v6.c

+1 −5
Original line number Diff line number Diff line
@@ -581,9 +581,5 @@ static struct platform_driver armv6_pmu_driver = { 
	.probe		= armv6_pmu_device_probe,

};



static int __init register_armv6_pmu_driver(void)

{

	return platform_driver_register(&armv6_pmu_driver);

}

device_initcall(register_armv6_pmu_driver);

builtin_platform_driver(armv6_pmu_driver);

#endif	/* CONFIG_CPU_V6 || CONFIG_CPU_V6K */