Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/1.2/patches/831236/?format=api
{ "id": 831236, "url": "http://patchwork.ozlabs.org/api/1.2/patches/831236/?format=api", "web_url": "http://patchwork.ozlabs.org/project/glibc/patch/1509101470-7881-27-git-send-email-Dave.Martin@arm.com/", "project": { "id": 41, "url": "http://patchwork.ozlabs.org/api/1.2/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": "<1509101470-7881-27-git-send-email-Dave.Martin@arm.com>", "list_archive_url": null, "date": "2017-10-27T10:51:08", "name": "[v4,26/28] arm64/sve: Add documentation", "commit_ref": null, "pull_url": null, "state": "new", "archived": false, "hash": "13435a589d41c10696bd9a604120d315fa2e0937", "submitter": { "id": 26612, "url": "http://patchwork.ozlabs.org/api/1.2/people/26612/?format=api", "name": "Dave Martin", "email": "Dave.Martin@arm.com" }, "delegate": null, "mbox": "http://patchwork.ozlabs.org/project/glibc/patch/1509101470-7881-27-git-send-email-Dave.Martin@arm.com/mbox/", "series": [ { "id": 10555, "url": "http://patchwork.ozlabs.org/api/1.2/series/10555/?format=api", "web_url": "http://patchwork.ozlabs.org/project/glibc/list/?series=10555", "date": "2017-10-27T10:50:42", "name": "ARM Scalable Vector Extension (SVE)", "version": 4, "mbox": "http://patchwork.ozlabs.org/series/10555/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/831236/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/831236/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<libc-alpha-return-86469-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-86469-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=\"XTu3veQE\"; 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 3yNgmB6hHVz9rxj\n\tfor <incoming@patchwork.ozlabs.org>;\n\tFri, 27 Oct 2017 21:56:26 +1100 (AEDT)", "(qmail 121963 invoked by alias); 27 Oct 2017 10:52:16 -0000", "(qmail 121866 invoked by uid 89); 27 Oct 2017 10:52:15 -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=OeubUKjAd49mb5CDgrRtv1+Lu3vxf6i40LcEqLAY4fd\n\tGeYVehrNz2c2sy2/2OaQZNgo8WINP3Hc61dNIyV4hNMyR+0gYUVTetkPh/xdViDE\n\tUAJz8QWG6m1OuZ28f9e/Hl+Ok2Z7zYhz4ZblKATZvj3YWJP/d9slutKpnh+JqJek\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=ZyCoPVeSn1kFwgVNf3S1GjGaFBo=; b=XTu3veQEJOVpD7y1Z\n\t1yqf9h0Vl3gLpzPym/xzNDHSoDuModNkGrXbA7uO6keZRSIQWyPOTzjjHVcfWozt\n\tKgFvWs9/qYOSm4t4wQ0/nrcp2g/8C/MO7GrvtP07qOCMcAeDiJ2eoXdyZfDM5D0m\n\taku7HUspNWgB56BNRRaRDyC4eQ=", "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, SPF_PASS autolearn=ham version=3.3.2 spammy=", "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>, Okamoto Takayuki\n\t<tokamoto@jp.fujitsu.com>, \tkvmarm@lists.cs.columbia.edu,\n\tlibc-alpha@sourceware.org, \tlinux-arch@vger.kernel.org,\n\tAlan Hayward <alan.hayward@arm.com>,\n\tMark Rutland <mark.rutland@arm.com>, Michael Kerrisk\n\t<mtk.manpages@gmail.com>, \tlinux-api@vger.kernel.org", "Subject": "[PATCH v4 26/28] arm64/sve: Add documentation", "Date": "Fri, 27 Oct 2017 11:51:08 +0100", "Message-Id": "<1509101470-7881-27-git-send-email-Dave.Martin@arm.com>", "In-Reply-To": "<1509101470-7881-1-git-send-email-Dave.Martin@arm.com>", "References": "<1509101470-7881-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: Alan Hayward <alan.hayward@arm.com>\nCc: Alex Bennée <alex.bennee@linaro.org>\nCc: Mark Rutland <mark.rutland@arm.com>\nCc: Michael Kerrisk <mtk.manpages@gmail.com>\nCc: Szabolcs Nagy <szabolcs.nagy@arm.com>\nCc: linux-api@vger.kernel.org\n\n---\n\nChanges since v3\n----------------\n\nChanges requested by Catalin Marinas\n\n * Typo fix: SIG_SVE_ -> SVE_SIG_ in sigcontext macro names.\n---\n Documentation/arm64/sve.txt | 508 +++++++++++++++++++++++++++++++\n arch/arm64/include/uapi/asm/sigcontext.h | 3 +\n 2 files changed, 511 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..f128f73\n--- /dev/null\n+++ b/Documentation/arm64/sve.txt\n@@ -0,0 +1,508 @@\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+* All other SVE state of a thread, including the currently configured vector\n+ length, the state of the PR_SVE_VL_INHERIT flag, and the deferred vector\n+ length (if any), is preserved across all syscalls, subject to the specific\n+ exceptions for execve() described in section 6.\n+\n+ In particular, on return from a fork() or clone(), the parent and new child\n+ process or thread share identical SVE configuration, matching that of the\n+ parent before the call.\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 SVE_SIG_* 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. Other threads of the calling process are unaffected.\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 performed by this thread.\n+\n+\t The effect is equivalent to implicit exceution of the following\n+\t call immediately after the next execve() (if any) by the thread:\n+\n+\t\tprctl(PR_SVE_SET_VL, arg & ~PR_SVE_SET_VL_ONEXEC)\n+\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+\n+\t Without PR_SVE_SET_VL_ONEXEC, the requested change takes effect\n+\t immediately.\n+\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+\n+ On success:\n+\n+ * Either the calling thread's vector length or the deferred vector length\n+ to be applied at the next execve() by the thread (dependent on whether\n+ PR_SVE_SET_VL_ONEXEC is present in arg), is set to the largest value\n+ supported by the system that is less than or equal to vl. If vl ==\n+ SVE_VL_MAX, the value set will be the largest value supported by the\n+ system.\n+\n+ * Any previously outstanding deferred vector length change in the calling\n+ thread is cancelled.\n+\n+ * The returned value describes the resulting configuration, encoded as for\n+ PR_SVE_GET_VL. The vector length reported in this value is the new\n+ current vector length for this thread if PR_SVE_SET_VL_ONEXEC was not\n+ present in arg; otherwise, the reported vector length is the deferred\n+ vector length that will be applied at the next execve() by the calling\n+ thread.\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, or calling PR_SVE_SET_VL with the PR_SVE_SET_VL_ONEXEC\n+ flag, does not constitute a change to the vector length for this 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+ The caller must make a further GETREGSET call if it needs to know what VL is\n+ actually set by SETREGSET, unless is it known in advance that the requested\n+ VL is supported.\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/sys/abi/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 7654a81..3c0b484 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\t16\t/* number of bytes per quadword */\n \n", "prefixes": [ "v4", "26/28" ] }