Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/808353/?format=api
{ "id": 808353, "url": "http://patchwork.ozlabs.org/api/patches/808353/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-imx/patch/1504198860-12951-27-git-send-email-Dave.Martin@arm.com/", "project": { "id": 19, "url": "http://patchwork.ozlabs.org/api/projects/19/?format=api", "name": "Linux IMX development", "link_name": "linux-imx", "list_id": "linux-imx-kernel.lists.patchwork.ozlabs.org", "list_email": "linux-imx-kernel@lists.patchwork.ozlabs.org", "web_url": null, "scm_url": null, "webscm_url": null, "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/linux-imx/patch/1504198860-12951-27-git-send-email-Dave.Martin@arm.com/mbox/", "series": [ { "id": 883, "url": "http://patchwork.ozlabs.org/api/series/883/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-imx/list/?series=883", "date": "2017-08-31T17:00:33", "name": "ARM Scalable Vector Extension (SVE)", "version": 2, "mbox": "http://patchwork.ozlabs.org/series/883/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/808353/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/808353/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org>", "X-Original-To": "incoming-imx@patchwork.ozlabs.org", "Delivered-To": "patchwork-incoming-imx@bilbo.ozlabs.org", "Authentication-Results": [ "ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=<UNKNOWN>)", "ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"AVj4Ilnx\"; dkim-atps=neutral" ], "Received": [ "from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\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 3xjpk02CNnz9sD5\n\tfor <incoming-imx@patchwork.ozlabs.org>;\n\tFri, 1 Sep 2017 03:08:40 +1000 (AEST)", "from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnSxI-00059r-Bm; Thu, 31 Aug 2017 17:08:36 +0000", "from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dnSr2-0007JX-Nw for linux-arm-kernel@lists.infradead.org;\n\tThu, 31 Aug 2017 17:02:40 +0000", "from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E1AA4168F;\n\tThu, 31 Aug 2017 10:02:07 -0700 (PDT)", "from e103592.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com\n\t[10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id\n\t1E15F3F58F; Thu, 31 Aug 2017 10:02:05 -0700 (PDT)" ], "DKIM-Signature": "v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:\n\tMessage-Id:Date:Subject:To:From:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=PE+GCZcIBugbLRLC6FOOEh3MaaPWhQMfSaZupuaDZkQ=;\n\tb=AVj4Ilnx6qHTMv\n\t2yozNoPx+7MuENlmq5BKPn10nl7fVZbEoXMf/JZmjZLwPjY4wxWI2EVKIZaePadwChOppnRG05+ta\n\tmYZ8cHPYEYf4yGpRYPWb3x1WXdR1Iw03gv2aHlUMpWokL1BzOsgPY0hBlcAdOytxv/eOWx7xgqW1S\n\tgdEtHG0grfmpGLizVGnK5t7a+2FYOkrrXZJJrnjVKZpmN9lP7rQS8/W7ZjZMbEKY2O3BXQKirsz/+\n\t0I+prAroawv2EEg8e8EjDHIJxn78Ne1PG2P+AzFYJ/+JwHb9YPp0suHXT4KlCHUCmTr7noauLkoCe\n\tkCKg56OeR/QBRto2Z5NQ==;", "From": "Dave Martin <Dave.Martin@arm.com>", "To": "linux-arm-kernel@lists.infradead.org", "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>", "X-Mailer": "git-send-email 2.1.4", "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", "X-CRM114-Version": "20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ", "X-CRM114-CacheID": "sfid-20170831_100209_527949_E23C1F9C ", "X-CRM114-Status": "GOOD ( 32.26 )", "X-Spam-Score": "-6.9 (------)", "X-Spam-Report": "SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]", "X-BeenThere": "linux-arm-kernel@lists.infradead.org", "X-Mailman-Version": "2.1.21", "Precedence": "list", "List-Unsubscribe": "<http://lists.infradead.org/mailman/options/linux-arm-kernel>,\n\t<mailto:linux-arm-kernel-request@lists.infradead.org?subject=unsubscribe>", "List-Archive": "<http://lists.infradead.org/pipermail/linux-arm-kernel/>", "List-Post": "<mailto:linux-arm-kernel@lists.infradead.org>", "List-Help": "<mailto:linux-arm-kernel-request@lists.infradead.org?subject=help>", "List-Subscribe": "<http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>,\n\t<mailto:linux-arm-kernel-request@lists.infradead.org?subject=subscribe>", "Cc": "linux-arch@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>,\n\tlibc-alpha@sourceware.org, Ard Biesheuvel <ard.biesheuvel@linaro.org>, \n\tSzabolcs Nagy <szabolcs.nagy@arm.com>, \n\tCatalin Marinas <catalin.marinas@arm.com>,\n\tWill Deacon <will.deacon@arm.com>, Richard Sandiford\n\t<richard.sandiford@arm.com>, =?utf-8?q?Alex_Benn=C3=A9e?=\n\t<alex.bennee@linaro.org>, kvmarm@lists.cs.columbia.edu", "Content-Type": "text/plain; charset=\"utf-8\"", "Content-Transfer-Encoding": "base64", "Sender": "\"linux-arm-kernel\" <linux-arm-kernel-bounces@lists.infradead.org>", "Errors-To": "linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org", "List-Id": "linux-imx-kernel.lists.patchwork.ozlabs.org" }, "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" ] }