[{"id":1794823,"web_url":"http://patchwork.ozlabs.org/comment/1794823/","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 <Dave.Martin@arm.com>\n> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>\n> Cc: Alex Bennée <alex.bennee@linaro.org>\n\nReviewed-by: Catalin Marinas <catalin.marinas@arm.com>","headers":{"Return-Path":"<libc-alpha-return-86471-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-86471-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=\"AIC49tni\"; 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 3yNkBl1KRgz9t2h\n\tfor <incoming@patchwork.ozlabs.org>;\n\tFri, 27 Oct 2017 23:46:06 +1100 (AEDT)","(qmail 79853 invoked by alias); 27 Oct 2017 12:45:59 -0000","(qmail 79707 invoked by uid 89); 27 Oct 2017 12:45:58 -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:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-type:content-transfer-encoding\n\t:in-reply-to; q=dns; s=default; b=SpTUk+ruYpUfaoQlVu89P6ecx8FpOV\n\tMeKg/tTpdDfmyN5dGAMoieRrELd+uF2FyR/rFRWkm8vO6DMO5yxW0ytLqvzat+o+\n\tQP8L+hxPdz0QVVlLeb5LjMoeQCSdFt+/ks74yRD20LVkDOr4O5H3c8kcfMoiQwM1\n\tZx8GCfq6aydps=","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:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-type:content-transfer-encoding\n\t:in-reply-to; s=default; bh=PNCcwnhvMGPk1C6InxSjup/SHdo=; b=AIC4\n\t9tnilqAXK9mo6IwSbpw6gzdZhSC9fU2+bNvVmkGZNntbrVlZqDu9OfVLR4/OqE0g\n\tjeqgZpTI2f0T2dVZFSGjqSl01wkyxkzmt9A+QVJ5tULaJuoBm1MbvB3DOWnUvyeL\n\tNxOCZyyOw5uO6sUeC6Oypkz9MJUGnGdAcvcT0NI=","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=-1.9 required=5.0 tests=BAYES_00,\n\tRP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 spammy=","X-HELO":"foss.arm.com","Date":"Fri, 27 Oct 2017 13:45:51 +0100","From":"Catalin Marinas <catalin.marinas@arm.com>","To":"Dave Martin <Dave.Martin@arm.com>","Cc":"linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org,\n\tOkamoto Takayuki <tokamoto@jp.fujitsu.com>, \tlibc-alpha@sourceware.org,\n\tArd Biesheuvel <ard.biesheuvel@linaro.org>, Szabolcs Nagy\n\t<szabolcs.nagy@arm.com>, \tWill Deacon <will.deacon@arm.com>, Alex\n\t=?iso-8859-1?q?Benn=E9e?= <alex.bennee@linaro.org>,\n\tkvmarm@lists.cs.columbia.edu","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-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<1509101470-7881-12-git-send-email-Dave.Martin@arm.com>","User-Agent":"NeoMutt/20170113 (1.7.2)"}}]