From patchwork Tue Oct 13 17:22:28 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Suzuki K Poulose X-Patchwork-Id: 7387631 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 23AD0BEEA4 for ; Tue, 13 Oct 2015 17:33:18 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id DE5F020793 for ; Tue, 13 Oct 2015 17:33:16 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 97AF320788 for ; Tue, 13 Oct 2015 17:33:15 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Zm3Po-0001CZ-2I; Tue, 13 Oct 2015 17:31:08 +0000 Received: from eu-smtp-delivery-143.mimecast.com ([146.101.78.143]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Zm3JK-0006c2-6f for linux-arm-kernel@lists.infradead.org; Tue, 13 Oct 2015 17:24:34 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-12-leMdNK91QkGTwRsGm8M6Sg-9; Tue, 13 Oct 2015 18:23:11 +0100 Received: from e106634-lin.cambridge.arm.com ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2015 18:23:07 +0100 From: "Suzuki K. Poulose" To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v3 20/24] arm64: Documentation - Expose CPU feature registers Date: Tue, 13 Oct 2015 18:22:28 +0100 Message-Id: <1444756952-31145-21-git-send-email-suzuki.poulose@arm.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1444756952-31145-1-git-send-email-suzuki.poulose@arm.com> References: <1444756952-31145-1-git-send-email-suzuki.poulose@arm.com> X-OriginalArrivalTime: 13 Oct 2015 17:23:07.0131 (UTC) FILETIME=[D34A8CB0:01D105DB] X-MC-Unique: leMdNK91QkGTwRsGm8M6Sg-9 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20151013_102427_063562_6B82634C X-CRM114-Status: GOOD ( 22.23 ) X-Spam-Score: -4.2 (----) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, Vladimir.Murzin@arm.com, steve.capper@linaro.org, ryan.arnold@linaro.org, ard.biesheuvel@linaro.org, marc.zyngier@arm.com, catalin.marinas@arm.com, "Suzuki K. Poulose" , will.deacon@arm.com, linux-kernel@vger.kernel.org, edward.nevill@linaro.org, aph@redhat.com, james.morse@arm.com, andre.przywara@arm.com, dave.martin@arm.com, christoffer.dall@linaro.org MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Documentation for the infrastructure to expose CPU feature register by emulating MRS. Signed-off-by: Suzuki K. Poulose --- Documentation/arm64/cpu-feature-registers.txt | 225 +++++++++++++++++++++++++ 1 file changed, 225 insertions(+) create mode 100644 Documentation/arm64/cpu-feature-registers.txt diff --git a/Documentation/arm64/cpu-feature-registers.txt b/Documentation/arm64/cpu-feature-registers.txt new file mode 100644 index 0000000..41981cb --- /dev/null +++ b/Documentation/arm64/cpu-feature-registers.txt @@ -0,0 +1,225 @@ + ARM64 CPU Feature Registers + =========================== + +Author: Suzuki K. Poulose + + +This file describes the API for exporting the AArch64 CPU ID/feature registers +to userspace. + +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 ELF_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 restricted (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. Exposing the ID + registers avoids having to come up with HWCAP representations + and parsing code. + + +2. Requirements +----------------- + + a) Safety : + Applications should be able to use the information provided by the + infrastructure to run optimally 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 and the values of the fields are set to indicate the + feature is 'not supported' (See the 'visible' field in the + table in Section 4). 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/identification/ + \- midr + \- revidr + +The list of supported registers and the attributes of individual +feature bits are listed in section 4. Unless there is absolute necessity, +we don't encourage the addition of new feature registers to the list. +In any case, it should comply to the requirements listed above. + +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 + +(See Table C5-6 'System instruction encodings for System register accesses' + in ARMv8 ARM, 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 field marked as not 'visible', is set to indicate + the feature is missing (as defined by the architecture). + d) The value of a 'visible' field holds the system wide safe value + for the particular feature(except for MIDR_EL1, see section 4). + See Appendix I for more information on safe value. + +There are only a few registers visible to the userspace. See Section 4, +for the list of 'visible' registers. + +The registers which are either reserved RAZ or IMPLEMENTAION DEFINED are +emulated as 0. + +All others are emulated as having 'invisible' features. + +4. List of exposed registers +----------------------------- + + 1) ID_AA64ISAR0_EL1 - Instruction Set Attribute Register 0 + x--------------------------------------------------x + | Name | bits | visible | + |--------------------------------------------------| + | RAZ | [63-20] | n | + |--------------------------------------------------| + | CRC32 | [19-16] | y | + |--------------------------------------------------| + | SHA2 | [15-12] | y | + |--------------------------------------------------| + | SHA1 | [11-8] | y | + |--------------------------------------------------| + | AES | [7-4] | y | + |--------------------------------------------------| + | RAZ | [3-0] | n | + x--------------------------------------------------x + + 2) ID_AA64ISAR1_EL1 - Instruction Set Attribute Register 1 + x--------------------------------------------------x + | Name | bits | visible | + |--------------------------------------------------| + | RAZ | [63-0] | y | + x--------------------------------------------------x + + 3) ID_AA64PFR0_EL1 - Processor Feature Register 0 + x--------------------------------------------------x + | Name | bits | visible | + |--------------------------------------------------| + | RAZ | [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 + + 4) ID_AA64PFR1_EL1 - Processor Feature Register 1 + x--------------------------------------------------x + | Name | bits | visible | + |--------------------------------------------------| + | RAZ | [63-0] | y | + x--------------------------------------------------x + + 5) MIDR_EL1 - Main ID Register + x--------------------------------------------------x + | Name | bits | visible | + |--------------------------------------------------| + | RAZ | [63-32] | n | + |--------------------------------------------------| + | 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. CPUID feature value types + + The safe value of a CPUID feature field is dependent on the implications + of the values assigned to it by the architecture. Based on the relationship + between the values, the features are classified into 3 types. + + a) LOWER_SAFE - The value 'n+1' indicates, value 'n' and some + additional features. (where n >= 0). The smaller value (n) is + considered safer in this case. + + b) HIGHER_SAFE - The value 'n+1' is safer than 'n' (for n>= 0). + + c) EXACT - If the values of the feature don't have any relationship, + a predefined safe value is used. + +II. CPUID feature value scheme for features + + For features that are not of the EXACT type as described, the following rule applies. + Each 4bit field is a signed value, with RAZ as the original value defined by + the architecture. When a feature is added or extended the field is incremented. + If an existing feature(whose value is 0) is removed, the value becomes negative(0xf). + + e.g: 1) Value for ID_AA64PFR0:FP + 0 - Floating Point instructions supported. + 0xf - Floating Point instructions not supported. + + 2) Value for ID_AA64MMFR0:TGran16 + 0 - 16K page size not supported. + 1 - 16K page size supported.