Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/808345/?format=api
{ "id": 808345, "url": "http://patchwork.ozlabs.org/api/patches/808345/?format=api", "web_url": "http://patchwork.ozlabs.org/project/glibc/patch/1504198860-12951-27-git-send-email-Dave.Martin@arm.com/", "project": { "id": 41, "url": "http://patchwork.ozlabs.org/api/projects/41/?format=api", "name": "GNU C Library", "link_name": "glibc", "list_id": "libc-alpha.sourceware.org", "list_email": "libc-alpha@sourceware.org", "web_url": "", "scm_url": "", "webscm_url": "", "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<1504198860-12951-27-git-send-email-Dave.Martin@arm.com>", "list_archive_url": null, "date": "2017-08-31T17:00:58", "name": "[v2,26/28] arm64/sve: Add documentation", "commit_ref": null, "pull_url": null, "state": "new", "archived": false, "hash": "dff820f1fd7a070f7190e4b1d5d7d53b15d32a86", "submitter": { "id": 26612, "url": "http://patchwork.ozlabs.org/api/people/26612/?format=api", "name": "Dave Martin", "email": "Dave.Martin@arm.com" }, "delegate": null, "mbox": "http://patchwork.ozlabs.org/project/glibc/patch/1504198860-12951-27-git-send-email-Dave.Martin@arm.com/mbox/", "series": [ { "id": 882, "url": "http://patchwork.ozlabs.org/api/series/882/?format=api", "web_url": "http://patchwork.ozlabs.org/project/glibc/list/?series=882", "date": "2017-08-31T17:00:32", "name": "ARM Scalable Vector Extension (SVE)", "version": 2, "mbox": "http://patchwork.ozlabs.org/series/882/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/808345/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/808345/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<libc-alpha-return-83981-incoming=patchwork.ozlabs.org@sourceware.org>", "X-Original-To": "incoming@patchwork.ozlabs.org", "Delivered-To": [ "patchwork-incoming@bilbo.ozlabs.org", "mailing list libc-alpha@sourceware.org" ], "Authentication-Results": [ "ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-83981-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=<UNKNOWN>)", "ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"bofP1Hup\"; dkim-atps=neutral", "sourceware.org; auth=none" ], "Received": [ "from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xjpf70ZPYz9s81\n\tfor <incoming@patchwork.ozlabs.org>;\n\tFri, 1 Sep 2017 03:05:18 +1000 (AEST)", "(qmail 86171 invoked by alias); 31 Aug 2017 17:02:18 -0000", "(qmail 86119 invoked by uid 89); 31 Aug 2017 17:02:18 -0000" ], "DomainKey-Signature": "a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:from:to:cc:subject:date:message-id:in-reply-to\n\t:references:mime-version:content-type:content-transfer-encoding;\n\tq=dns; s=default; b=ILKPVlUqqrCB2a05+8WuYz0pFNwV8gm/+8w6pFvcE1R\n\tDdXy9LuABZXoYoQt5ZodmtqAaNAPmHLQ5fwAEU3znRfxPpCK0gWn/sCcGSycz/01\n\tfagRAnfvaZbO44MN9EWKdSylaOoyU/+j5SE1GgooCU55jA5xzQxK0S3vdPUw/20A\n\t=", "DKIM-Signature": "v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:from:to:cc:subject:date:message-id:in-reply-to\n\t:references:mime-version:content-type:content-transfer-encoding;\n\ts=default; bh=bTkOj2BORjqbuqyeOFIxhIZjQnk=; b=bofP1Hup8IFupNkfV\n\tKXfm5zHDMTDtXGE7lU2pelw7z/x8pBRQ8IKvZ31jduR5HAuZufDZTjhK+ONuWMNj\n\tzuDGwU0r9p6FBqUTh2zNWBLtGs5fD4muoVVioQrvSioTN2IC7Slyw1LMoileSEeS\n\tS/gNEcwJGtBwCfdIFaynL6e5/c=", "Mailing-List": "contact libc-alpha-help@sourceware.org; run by ezmlm", "Precedence": "bulk", "List-Id": "<libc-alpha.sourceware.org>", "List-Unsubscribe": "<mailto:libc-alpha-unsubscribe-incoming=patchwork.ozlabs.org@sourceware.org>", "List-Subscribe": "<mailto:libc-alpha-subscribe@sourceware.org>", "List-Archive": "<http://sourceware.org/ml/libc-alpha/>", "List-Post": "<mailto:libc-alpha@sourceware.org>", "List-Help": "<mailto:libc-alpha-help@sourceware.org>,\n\t<http://sourceware.org/ml/#faqs>", "Sender": "libc-alpha-owner@sourceware.org", "X-Virus-Found": "No", "X-Spam-SWARE-Status": "No, score=-26.1 required=5.0 tests=BAYES_00, GIT_PATCH_0,\n\tGIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS,\n\tRP_MATCHES_RCVD,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=interacting,\n\tmixture", "X-HELO": "foss.arm.com", "From": "Dave Martin <Dave.Martin@arm.com>", "To": "linux-arm-kernel@lists.infradead.org", "Cc": "Catalin Marinas <catalin.marinas@arm.com>, Will Deacon\n\t<will.deacon@arm.com>, \tArd Biesheuvel <ard.biesheuvel@linaro.org>,\n\t=?utf-8?q?Alex_Benn=C3=A9?= =?utf-8?q?e?= <alex.bennee@linaro.org>,\n\tSzabolcs Nagy <szabolcs.nagy@arm.com>, Richard Sandiford\n\t<richard.sandiford@arm.com>, \tkvmarm@lists.cs.columbia.edu,\n\tlibc-alpha@sourceware.org, \tlinux-arch@vger.kernel.org,\n\tMark Rutland <mark.rutland@arm.com>", "Subject": "[PATCH v2 26/28] arm64/sve: Add documentation", "Date": "Thu, 31 Aug 2017 18:00:58 +0100", "Message-Id": "<1504198860-12951-27-git-send-email-Dave.Martin@arm.com>", "In-Reply-To": "<1504198860-12951-1-git-send-email-Dave.Martin@arm.com>", "References": "<1504198860-12951-1-git-send-email-Dave.Martin@arm.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=UTF-8", "Content-Transfer-Encoding": "8bit" }, "content": "This patch adds basic documentation of the user/kernel interface\nprovided by the for SVE.\n\nSigned-off-by: Dave Martin <Dave.Martin@arm.com>\nCc: Alex Bennée <alex.bennee@linaro.org>\nCc: Mark Rutland <mark.rutland@arm.com>\n\n---\n\nChanges since v1\n----------------\n\nRequested by Alex Bennée:\n\n* Add cross-reference from sigcontext.h to the description of VL/VQ.\n\nOther:\n\n* [ABI fix] Bail out with -EIO if attempting to set the SVE regs for an\nunsupported VL, rather than misparsing the regset data.\n\n* Document detection of SVE via CPUID MRS.\n\n* Remove comment about coredump notes being padded for NT_ARM_SVE.\nThis is no longer the case with variable-size regsets supported\nin the core code.\n\n* Fix a missing bullet char\n---\n Documentation/arm64/sve.txt | 477 +++++++++++++++++++++++++++++++\n arch/arm64/include/uapi/asm/sigcontext.h | 3 +\n 2 files changed, 480 insertions(+)\n create mode 100644 Documentation/arm64/sve.txt", "diff": "diff --git a/Documentation/arm64/sve.txt b/Documentation/arm64/sve.txt\nnew file mode 100644\nindex 0000000..3c0f97f\n--- /dev/null\n+++ b/Documentation/arm64/sve.txt\n@@ -0,0 +1,477 @@\n+ Scalable Vector Extension support for AArch64 Linux\n+ ===================================================\n+\n+Author: Dave Martin <Dave.Martin@arm.com>\n+Date: 4 August 2017\n+\n+This document outlines briefly the interface provided to userspace by Linux in\n+order to support use of the ARM Scalable Vector Extension (SVE).\n+\n+This is an outline of the most important features and issues only and not\n+intended to be exhaustive.\n+\n+This document does not aim to describe the SVE architecture or programmer's\n+model. To aid understanding, a minimal description of relevant programmer's\n+model features for SVE is included in Appendix A.\n+\n+\n+1. General\n+-----------\n+\n+* SVE registers Z0..Z31, P0..P15 and FFR and the current vector length VL, are\n+ tracked per-thread.\n+\n+* The presence of SVE is reported to userspace via HWCAP_SVE in the aux vector\n+ AT_HWCAP entry. Presence of this flag implies the presence of the SVE\n+ instructions and registers, and the Linux-specific system interfaces\n+ described in this document. SVE is reported in /proc/cpuinfo as \"sve\".\n+\n+* Support for the execution of SVE instructions in userspace can also be\n+ detected by reading the CPU ID register ID_AA64PFR0_EL1 using an MRS\n+ instruction, and checking that the value of the SVE field is nonzero. [3]\n+\n+ It does not guarantee the presence of the system interfaces described in the\n+ following sections: software that needs to verify that those interfaces are\n+ present must check for HWCAP_SVE instead.\n+\n+* Debuggers should restrict themselves to interacting with the target via the\n+ NT_ARM_SVE regset. The recommended way of detecting support for this regset\n+ is to connect to a target process first and then attempt a\n+ ptrace(PTRACE_GETREGSET, pid, NT_ARM_SVE, &iov).\n+\n+\n+2. Vector length terminology\n+-----------------------------\n+\n+The size of an SVE vector (Z) register is referred to as the \"vector length\".\n+\n+To avoid confusion about the units used to express vector length, the kernel\n+adopts the following conventions:\n+\n+* Vector length (VL) = size of a Z-register in bytes\n+\n+* Vector quadwords (VQ) = size of a Z-register in units of 128 bits\n+\n+(So, VL = 16 * VQ.)\n+\n+The VQ convention is used where the underlying granularity is important, such\n+as in data structure definitions. In most other situations, the VL convention\n+is used. This is consistent with the meaning of the \"VL\" pseudo-register in\n+the SVE instruction set architecture.\n+\n+\n+3. System call behaviour\n+-------------------------\n+\n+* On syscall, V0..V31 are preserved (as without SVE). Thus, bits [127:0] of\n+ Z0..Z31 are preserved. All other bits of Z0..Z31, and all of P0..P15 and FFR\n+ become unspecified on return from a syscall.\n+\n+* The SVE registers are not used to pass arguments to or receive results from\n+ any syscall.\n+\n+* In practice the affected registers/bits will be preserved or will be replaced\n+ with zeros on return from a syscall, but userspace should not make\n+ assumptions about this. The kernel behaviour may vary on a case-by-case\n+ basis.\n+\n+\n+4. Signal handling\n+-------------------\n+\n+* A new signal frame record sve_context encodes the SVE registers on signal\n+ delivery. [1]\n+\n+* This record is supplementary to fpsimd_context. The FPSR and FPCR registers\n+ are only present in fpsimd_context. For convenience, the content of V0..V31\n+ is duplicated between sve_context and fpsimd_context.\n+\n+* The signal frame record for SVE always contains basic metadata, in particular\n+ the thread's vector length (in sve_context.vl).\n+\n+* The SVE registers may or may not be included in the record, depending on\n+ whether the registers are live for the thread. The registers are present if\n+ and only if:\n+ sve_context.head.size >= SVE_SIG_CONTEXT_SIZE(sve_vq_from_vl(sve_context.vl)).\n+\n+* If the registers are present, the remainder of the record has a vl-dependent\n+ size and layout. Macros SIG_SVE_* are defined [1] to facilitate access to\n+ the members.\n+\n+* If the SVE context is too big to fit in sigcontext.__reserved[], then extra\n+ space is allocated on the stack, an extra_context record is written in\n+ __reserved[] referencing this space. sve_context is then written in the\n+ extra space. Refer to [1] for further details about this mechanism.\n+\n+\n+5. Signal return\n+-----------------\n+\n+When returning from a signal handler:\n+\n+* If there is no sve_context record in the signal frame, or if the record is\n+ present but contains no register data as desribed in the previous section,\n+ then the SVE registers/bits become non-live and take unspecified values.\n+\n+* If sve_context is present in the signal frame and contains full register\n+ data, the SVE registers become live and are populated with the specified\n+ data. However, for backward compatibility reasons, bits [127:0] of Z0..Z31\n+ are always restored from the corresponding members of fpsimd_context.vregs[]\n+ and not from sve_context. The remaining bits are restored from sve_context.\n+\n+* Inclusion of fpsimd_context in the signal frame remains mandatory,\n+ irrespective of whether sve_context is present or not.\n+\n+* The vector length cannot be changed via signal return. If sve_context.vl in\n+ the signal frame does not match the current vector length, the signal return\n+ attempt is treated as illegal, resulting in a forced SIGSEGV.\n+\n+\n+6. prctl extensions\n+--------------------\n+\n+Some new prctl() calls are added to allow programs to manage the SVE vector\n+length:\n+\n+prctl(PR_SVE_SET_VL, unsigned long arg)\n+\n+ Sets the vector length of the calling thread and related flags, where\n+ arg == vl | flags.\n+\n+ vl is the desired vector length, where sve_vl_valid(vl) must be true.\n+\n+ flags:\n+\n+\tPR_SVE_SET_VL_INHERIT\n+\n+\t Inherit the current vector length across execve(). Otherwise, the\n+\t vector length is reset to the system default at execve(). (See\n+\t Section 9.)\n+\n+\tPR_SVE_SET_VL_ONEXEC\n+\n+\t Defer the requested vector length change until the next execve().\n+\t This allows launching of a new program with a different vector\n+\t length, while avoiding runtime side effects in the caller.\n+\n+\t This also overrides the effect of PR_SVE_SET_VL_INHERIT for the\n+\t first execve().\n+\n+\t Without PR_SVE_SET_VL_ONEXEC, any outstanding deferred vector\n+\t length change is cancelled.\n+\n+ Return value: a nonnegative on success, or a negative value on error:\n+\tEINVAL: SVE not supported, invalid vector length requested, or\n+\t invalid flags.\n+\n+ On success, the calling thread's vector length is changed to the largest\n+ value supported by the system that is less than or equal to vl.\n+ If vl == SVE_VL_MAX, the calling thread's vector length is changed to the\n+ largest value supported by the system.\n+\n+ The returned value describes the resulting configuration, encoded as for\n+ PR_SVE_GET_VL.\n+\n+ Changing the vector length causes all of P0..P15, FFR and all bits of\n+ Z0..V31 except for Z0 bits [127:0] .. Z31 bits [127:0] to become\n+ unspecified. Calling PR_SVE_SET_VL with vl equal to the thread's current\n+ vector length does not constitute a change to the vector length for this\n+ purpose.\n+\n+\n+prctl(PR_SVE_GET_VL)\n+\n+ Gets the vector length of the calling thread.\n+\n+ The following flag may be OR-ed into the result:\n+\n+\tPR_SVE_SET_VL_INHERIT\n+\n+\t Vector length will be inherited across execve().\n+\n+ There is no way to determine whether there is an outstanding deferred\n+ vector length change (which would only normally be the case between a\n+ fork() or vfork() and the corresponding execve() in typical use).\n+\n+ To extract the vector length from the result, and it with\n+ PR_SVE_VL_LEN_MASK.\n+\n+ Return value: a nonnegative value on success, or a negative value on error:\n+\tEINVAL: SVE not supported.\n+\n+\n+7. ptrace extensions\n+---------------------\n+\n+* A new regset NT_ARM_SVE is defined for use with PTRACE_GETREGSET and\n+ PTRACE_SETREGSET.\n+\n+ Refer to [2] for definitions.\n+\n+The regset data starts with struct user_sve_header, containing:\n+\n+ size\n+\n+\tSize of the complete regset, in bytes.\n+\tThis depends on vl and possibly on other things in the future.\n+\n+\tIf a call to PTRACE_GETREGSET requests less data than the value of\n+\tsize, the caller can allocate a larger buffer and retry in order to\n+\tread the complete regset.\n+\n+ max_size\n+\n+\tMaximum size in bytes that the regset can grow to for the target\n+\tthread. The regset won't grow bigger than this even if the target\n+\tthread changes its vector length etc.\n+\n+ vl\n+\n+\tTarget thread's current vector length, in bytes.\n+\n+ max_vl\n+\n+\tMaximum possible vector length for the target thread.\n+\n+ flags\n+\n+\teither\n+\n+\t SVE_PT_REGS_FPSIMD\n+\n+\t\tSVE registers are not live (GETREGSET) or are to be made\n+\t\tnon-live (SETREGSET).\n+\n+\t\tThe payload is of type struct user_fpsimd_state, with the same\n+\t\tmeaning as for NT_PRFPREG, starting at offset\n+\t\tSVE_PT_FPSIMD_OFFSET from the start of user_sve_header.\n+\n+\t\tExtra data might be appended in the future: the size of the\n+\t\tpayload should be obtained using SVE_PT_FPSIMD_SIZE(vq, flags).\n+\n+\t\tvq should be obtained using sve_vq_from_vl(vl).\n+\n+\t\tor\n+\n+\t SVE_PT_REGS_SVE\n+\n+\t\tSVE registers are live (GETREGSET) or are to be made live\n+\t\t(SETREGSET).\n+\n+\t\tThe payload contains the SVE register data, starting at offset\n+\t\tSVE_PT_SVE_OFFSET from the start of user_sve_header, and with\n+\t\tsize SVE_PT_SVE_SIZE(vq, flags);\n+\n+\t... OR-ed with zero or more of the following flags, which have the same\n+\tmeaning and behaviour as the corresponding PR_SET_VL_* flags:\n+\n+\t SVE_PT_VL_INHERIT\n+\n+\t SVE_PT_VL_ONEXEC (SETREGSET only).\n+\n+* The effects of changing the vector length and/or flags are equivalent to\n+ those documented for PR_SVE_SET_VL.\n+\n+* In the SVE_PT_REGS_SVE case, the size and layout of the payload depends on\n+ the header fields. The SVE_PT_SVE_*() macros are provided to facilitate\n+ access to the members.\n+\n+* In either case, for SETREGSET it is permissible to omit the payload, in which\n+ case only the vector length and flags are changed (along with any\n+ consequences of those changes).\n+\n+* For SETREGSET, if an SVE_PT_REGS_SVE payload is present and the\n+ requested VL is not supported, the effect will be the same as if the\n+ payload were omitted, except that an EIO error is reported. No\n+ attempt is made to translate the payload data to the correct layout\n+ for the vector length actually set. The thread's FPSIMD state is\n+ preserved, but the remaining bits of the SVE registers become\n+ unspecified. It is up to the caller to translate the payload layout\n+ for the actual VL and retry.\n+\n+* The effect of writing a partial, incomplete payload is unspecified.\n+\n+\n+8. ELF coredump extensions\n+---------------------------\n+\n+* A NT_ARM_SVE note will be added to each coredump for each thread of the\n+ dumped process. The contents will be equivalent to the data that would have\n+ been read if a PTRACE_GETREGSET of NT_ARM_SVE were executed for each thread\n+ when the coredump was generated.\n+\n+\n+9. System runtime configuration\n+--------------------------------\n+\n+* To mitigate the ABI impact of expansion of the signal frame, a policy\n+ mechanism is provided for administrators, distro maintainers and developers\n+ to set the default vector length for userspace processes:\n+\n+/proc/cpu/sve_default_vector_length\n+\n+ Writing the text representation of an integer to this file sets the system\n+ default vector length to the specified value, unless the value is greater\n+ than the maximum vector length supported by the system in which case the\n+ default vector length is set to that maximum.\n+\n+ The result can be determined by reopening the file and reading its\n+ contents.\n+\n+ At boot, the default vector length is initially set to 64 or the maximum\n+ supported vector length, whichever is smaller. This determines the initial\n+ vector length of the init process (PID 1).\n+\n+ Reading this file returns the current system default vector length.\n+\n+* At every execve() call, the new vector length of the new process is set to\n+ the system default vector length, unless\n+\n+ * PR_SVE_SET_VL_INHERIT (or equivalently SVE_PT_VL_INHERIT) is set for the\n+ calling thread, or\n+\n+ * a deferred vector length change is pending, established via the\n+ PR_SVE_SET_VL_ONEXEC flag (or SVE_PT_VL_ONEXEC).\n+\n+* Modifying the system default vector length does not affect the vector length\n+ of any existing process or thread that does not make an execve() call.\n+\n+\n+Appendix A. SVE programmer's model (informative)\n+=================================================\n+\n+This section provides a minimal description of the additions made by SVE to the\n+ARMv8-A programmer's model that are relevant to this document.\n+\n+Note: This section is for information only and not intended to be complete or\n+to replace any architectural specification.\n+\n+A.1. Registers\n+---------------\n+\n+In A64 state, SVE adds the following:\n+\n+* 32 8VL-bit vector registers Z0..Z31\n+ For each Zn, Zn bits [127:0] alias the ARMv8-A vector register Vn.\n+\n+ A register write using a Vn register name zeros all bits of the corresponding\n+ Zn except for bits [127:0].\n+\n+* 16 VL-bit predicate registers P0..P15\n+\n+* 1 VL-bit special-purpose predicate register FFR (the \"first-fault register\")\n+\n+* a VL \"pseudo-register\" that determines the size of each vector register\n+\n+ The SVE instruction set architecture provides no way to write VL directly.\n+ Instead, it can be modified only by EL1 and above, by writing appropriate\n+ system registers.\n+\n+* The value of VL can be configured at runtime by EL1 and above:\n+ 16 <= VL <= VLmax, where VL must be a multiple of 16.\n+\n+* The maximum vector length is determined by the hardware:\n+ 16 <= VLmax <= 256.\n+\n+ (The SVE architecture specifies 256, but permits future architecture\n+ revisions to raise this limit.)\n+\n+* FPSR and FPCR are retained from ARMv8-A, and interact with SVE floating-point\n+ operations in a similar way to the way in which they interact with ARMv8\n+ floating-point operations.\n+\n+ 8VL-1 128 0 bit index\n+ +---- //// -----------------+\n+ Z0 | : V0 |\n+ : :\n+ Z7 | : V7 |\n+ Z8 | : * V8 |\n+ : : :\n+ Z15 | : *V15 |\n+ Z16 | : V16 |\n+ : :\n+ Z31 | : V31 |\n+ +---- //// -----------------+\n+ 31 0\n+ VL-1 0 +-------+\n+ +---- //// --+ FPSR | |\n+ P0 | | +-------+\n+ : | | *FPCR | |\n+ P15 | | +-------+\n+ +---- //// --+\n+ FFR | | +-----+\n+ +---- //// --+ VL | |\n+ +-----+\n+\n+(*) callee-save:\n+ This only applies to bits [63:0] of Z-/V-registers.\n+ FPCR contains callee-save and caller-save bits. See [4] for details.\n+\n+\n+A.2. Procedure call standard\n+-----------------------------\n+\n+The ARMv8-A base procedure call standard is extended as follows with respect to\n+the additional SVE register state:\n+\n+* All SVE register bits that are not shared with FP/SIMD are caller-save.\n+\n+* Z8 bits [63:0] .. Z15 bits [63:0] are callee-save.\n+\n+ This follows from the way these bits are mapped to V8..V15, which are caller-\n+ save in the base procedure call standard.\n+\n+\n+Appendix B. ARMv8-A FP/SIMD programmer's model\n+===============================================\n+\n+Note: This section is for information only and not intended to be complete or\n+to replace any architectural specification.\n+\n+Refer to [4] for for more information.\n+\n+ARMv8-A defines the following floating-point / SIMD register state:\n+\n+* 32 128-bit vector registers V0..V31\n+* 2 32-bit status/control registers FPSR, FPCR\n+\n+ 127 0 bit index\n+ +---------------+\n+ V0 | |\n+ : : :\n+ V7 | |\n+ * V8 | |\n+ : : : :\n+ *V15 | |\n+ V16 | |\n+ : : :\n+ V31 | |\n+ +---------------+\n+\n+ 31 0\n+ +-------+\n+ FPSR | |\n+ +-------+\n+ *FPCR | |\n+ +-------+\n+\n+(*) callee-save:\n+ This only applies to bits [63:0] of V-registers.\n+ FPCR contains a mixture of callee-save and caller-save bits.\n+\n+\n+References\n+==========\n+\n+[1] arch/arm64/include/uapi/asm/sigcontext.h\n+ AArch64 Linux signal ABI definitions\n+\n+[2] arch/arm64/include/uapi/asm/ptrace.h\n+ AArch64 Linux ptrace ABI definitions\n+\n+[3] linux/Documentation/arm64/cpu-feature-registers.txt\n+\n+[4] ARM IHI0055C\n+ http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055c/IHI0055C_beta_aapcs64.pdf\n+ http://infocenter.arm.com/help/topic/com.arm.doc.subset.swdev.abi/index.html\n+ Procedure Call Standard for the ARM 64-bit Architecture (AArch64)\ndiff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h\nindex c78cf8e..dc9f5f4 100644\n--- a/arch/arm64/include/uapi/asm/sigcontext.h\n+++ b/arch/arm64/include/uapi/asm/sigcontext.h\n@@ -133,6 +133,9 @@ struct sve_context {\n * The SVE architecture leaves space for future expansion of the\n * vector length beyond its initial architectural limit of 2048 bits\n * (16 quadwords).\n+ *\n+ * See linux/Documentation/arm64/sve.txt for a description of the VL/VQ\n+ * terminology.\n */\n #define SVE_VQ_BYTES\t\t0x10\t/* number of bytes per quadword */\n \n", "prefixes": [ "v2", "26/28" ] }