[{"id":1794826,"web_url":"http://patchwork.ozlabs.org/comment/1794826/","msgid":"<20171027124550.hul2skr5uxxwidbr@armageddon.cambridge.arm.com>","list_archive_url":null,"date":"2017-10-27T12:45:51","subject":"Re: [PATCH v4 11/28] arm64/sve: Core task context handling","submitter":{"id":938,"url":"http://patchwork.ozlabs.org/api/people/938/","name":"Catalin Marinas","email":"catalin.marinas@arm.com"},"content":"On Fri, Oct 27, 2017 at 11:50:53AM +0100, Dave P Martin wrote:\n> This patch adds the core support for switching and managing the SVE\n> architectural state of user tasks.\n> \n> Calls to the existing FPSIMD low-level save/restore functions are\n> factored out as new functions task_fpsimd_{save,load}(), since SVE\n> now dynamically may or may not need to be handled at these points\n> depending on the kernel configuration, hardware features discovered\n> at boot, and the runtime state of the task. To make these\n> decisions as fast as possible, const cpucaps are used where\n> feasible, via the system_supports_sve() helper.\n> \n> The SVE registers are only tracked for threads that have explicitly\n> used SVE, indicated by the new thread flag TIF_SVE. Otherwise, the\n> FPSIMD view of the architectural state is stored in\n> thread.fpsimd_state as usual.\n> \n> When in use, the SVE registers are not stored directly in\n> thread_struct due to their potentially large and variable size.\n> Because the task_struct slab allocator must be configured very\n> early during kernel boot, it is also tricky to configure it\n> correctly to match the maximum vector length provided by the\n> hardware, since this depends on examining secondary CPUs as well as\n> the primary. Instead, a pointer sve_state in thread_struct points\n> to a dynamically allocated buffer containing the SVE register data,\n> and code is added to allocate and free this buffer at appropriate\n> times.\n> \n> TIF_SVE is set when taking an SVE access trap from userspace, if\n> suitable hardware support has been detected. This enables SVE for\n> the thread: a subsequent return to userspace will disable the trap\n> accordingly. If such a trap is taken without sufficient system-\n> wide hardware support, SIGILL is sent to the thread instead as if\n> an undefined instruction had been executed: this may happen if\n> userspace tries to use SVE in a system where not all CPUs support\n> it for example.\n> \n> The kernel will clear TIF_SVE and disable SVE for the thread\n> whenever an explicit syscall is made by userspace. For backwards\n> compatibility reasons and conformance with the spirit of the base\n> AArch64 procedure call standard, the subset of the SVE register\n> state that aliases the FPSIMD registers is still preserved across a\n> syscall even if this happens. The remainder of the SVE register\n> state logically becomes zero at syscall entry, though the actual\n> zeroing work is currently deferred until the thread next tries to\n> use SVE, causing another trap to the kernel. This implementation\n> is suboptimal: in the future, the fastpath case may be optimised\n> to zero the registers in-place and leave SVE enabled for the task,\n> where beneficial.\n> \n> TIF_SVE is also cleared in the following slowpath cases, which are\n> taken as reasonable hints that the task may no longer use SVE:\n> * exec\n> * fork and clone\n> \n> Code is added to sync data between thread.fpsimd_state and\n> thread.sve_state whenever enabling/disabling SVE, in a manner\n> consistent with the SVE architectural programmer's model.\n> \n> Signed-off-by: Dave Martin \n> Cc: Ard Biesheuvel \n> Cc: Alex Bennée \n\nReviewed-by: Catalin Marinas ","headers":{"Return-Path":"","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=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"gMYvKJbb\"; 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 3yNkCj5SBwz9s72\n\tfor ;\n\tFri, 27 Oct 2017 23:46:57 +1100 (AEDT)","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 1e842E-0001EP-Iv; Fri, 27 Oct 2017 12:46:50 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e841g-0007eE-5J for linux-arm-kernel@lists.infradead.org;\n\tFri, 27 Oct 2017 12:46:18 +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 78C151596;\n\tFri, 27 Oct 2017 05:45:55 -0700 (PDT)","from armageddon.cambridge.arm.com (armageddon.cambridge.arm.com\n\t[10.1.206.84])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\tAD6CF3F5C0; Fri, 27 Oct 2017 05:45:53 -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:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=mpd1I84FnaT9eaKRG7LfumOCQL4SymKBTLpU383iQqs=;\n\tb=gMYvKJbbnDDSku\n\tvT7IxKzUVDzhqsOTmN+Rcsae8AjafLUlkp1IE0ZE9Qtl5pBW5aBRdTYEc2vJ0i1fO6ZQuBS6pfISl\n\tpRvEyxuVt57TwEHzmdBUUebBzptfIEcHbofV1FdKuwFtDqX89aEMKTQedb9Zlbc8jHXm26WAub5Ju\n\tV6IjuIhoqSfhCefOsL3yaOrp39hfry9YM6QdztEoaJtmcLacFpNJXsVikwVftH8eysq1O5Gg665Z2\n\txAhIVc9+N4v06wirlf0hk/g4mBTmBnk3D1t2UQ8tRL45i/lR0R3tcngIBXINTt1uL80pMzd4cLd8F\n\t0IrV1DZUQWYEBm2jShgg==;","Date":"Fri, 27 Oct 2017 13:45:51 +0100","From":"Catalin Marinas ","To":"Dave Martin ","Subject":"Re: [PATCH v4 11/28] arm64/sve: Core task context handling","Message-ID":"<20171027124550.hul2skr5uxxwidbr@armageddon.cambridge.arm.com>","References":"<1509101470-7881-1-git-send-email-Dave.Martin@arm.com>\n\t<1509101470-7881-12-git-send-email-Dave.Martin@arm.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<1509101470-7881-12-git-send-email-Dave.Martin@arm.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171027_054616_301523_5C880440 ","X-CRM114-Status":"GOOD ( 18.95 )","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":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"linux-arch@vger.kernel.org, Okamoto Takayuki ,\n\tlibc-alpha@sourceware.org, Ard Biesheuvel , \n\tSzabolcs Nagy , Will Deacon ,\n\tAlex =?iso-8859-1?q?Benn=E9e?= ,\n\tkvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"iso-8859-1\"","Content-Transfer-Encoding":"quoted-printable","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}}]