[{"id":1768052,"web_url":"http://patchwork.ozlabs.org/comment/1768052/","msgid":"<20170913172911.3ca2h6cpju7etifi@localhost>","list_archive_url":null,"date":"2017-09-13T17:29:11","subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","submitter":{"id":938,"url":"http://patchwork.ozlabs.org/api/people/938/","name":"Catalin Marinas","email":"catalin.marinas@arm.com"},"content":"On Thu, Aug 31, 2017 at 06:00:46PM +0100, Dave P Martin wrote:\n> This patch implements the core logic for changing a task's vector\n> length on request from userspace.  This will be used by the ptrace\n> and prctl frontends that are implemented in later patches.\n> \n> The SVE architecture permits, but does not require, implementations\n> to support vector lengths that are not a power of two.  To handle\n> this, logic is added to check a requested vector length against a\n> possibly sparse bitmap of available vector lengths at runtime, so\n> that the best supported value can be chosen.\n> \n> Signed-off-by: Dave Martin <Dave.Martin@arm.com>\n> Cc: Alex Bennée <alex.bennee@linaro.org>\n\nCan this be merged with patch 20? It seems to add the PR_ definitions\nwhich get actually used later when the prctl interface is added.","headers":{"Return-Path":"<libc-alpha-return-84569-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-84569-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=\"ssmizcVQ\"; 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 3xspZ159yZz9sNV\n\tfor <incoming@patchwork.ozlabs.org>;\n\tThu, 14 Sep 2017 03:29:29 +1000 (AEST)","(qmail 10005 invoked by alias); 13 Sep 2017 17:29:18 -0000","(qmail 9486 invoked by uid 89); 13 Sep 2017 17:29:17 -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=HW0ftB1J372ocOJdEWVSmmnXhnOjsU\n\t54vKmRgH0Ct4EzRPNbIyuFls+bMXyGd0e+j/g7kr093M3gHiJXKJklVwx8YRb+Ng\n\tW/8er/HSi6VJQxRc+aEyfB792IMTLwZd7VPjbvk8EZAzmdqk3sLeMUEUGVWqhTNb\n\tBpB9sWO8Wz85s=","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=9LW+S1jQw3HNOj9TipasURvW1Yo=; b=ssmi\n\tzcVQdybH0piSKHBskJxKjJoHHhezfIXel+6DmWAy1mOM8+b+drMoxAacvubXpYY6\n\tkhPWT4778yzdABujl3Ip0lDYRvX9Y9O/W0cmPntcEiMhyphvRMOpUEQRI2/G5YEf\n\tePqlNAAUeRZtpriVlM8hG+WQzj+f5G3J/e2Q2OQ=","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\n\tspammy=HContent-Transfer-Encoding:8bit","X-Spam-User":"qpsmtpd, 2 recipients","X-HELO":"foss.arm.com","Date":"Wed, 13 Sep 2017 10:29:11 -0700","From":"Catalin Marinas <catalin.marinas@arm.com>","To":"Dave Martin <Dave.Martin@arm.com>","Cc":"linux-arm-kernel@lists.infradead.org, Will Deacon <will.deacon@arm.com>, \n\tArd Biesheuvel <ard.biesheuvel@linaro.org>, Alex =?iso-8859-1?q?Benn?=\n\t=?iso-8859-1?q?=E9e?= <alex.bennee@linaro.org>,\n\tSzabolcs Nagy <szabolcs.nagy@arm.com>, Richard Sandiford\n\t<richard.sandiford@arm.com>, kvmarm@lists.cs.columbia.edu,\n\tlibc-alpha@sourceware.org, \n\tlinux-arch@vger.kernel.org, gdb@sourceware.org,\n\tAlan Hayward <alan.hayward@arm.com>, Yao Qi <Yao.Qi@arm.com>","Subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","Message-ID":"<20170913172911.3ca2h6cpju7etifi@localhost>","References":"<1504198860-12951-1-git-send-email-Dave.Martin@arm.com>\n\t<1504198860-12951-15-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":"<1504198860-12951-15-git-send-email-Dave.Martin@arm.com>","User-Agent":"NeoMutt/20170113 (1.7.2)"}},{"id":1768089,"web_url":"http://patchwork.ozlabs.org/comment/1768089/","msgid":"<20170913190611.GC23415@e103592.cambridge.arm.com>","list_archive_url":null,"date":"2017-09-13T19:06:12","subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","submitter":{"id":26612,"url":"http://patchwork.ozlabs.org/api/people/26612/","name":"Dave Martin","email":"Dave.Martin@arm.com"},"content":"On Wed, Sep 13, 2017 at 10:29:11AM -0700, Catalin Marinas wrote:\n> On Thu, Aug 31, 2017 at 06:00:46PM +0100, Dave P Martin wrote:\n> > This patch implements the core logic for changing a task's vector\n> > length on request from userspace.  This will be used by the ptrace\n> > and prctl frontends that are implemented in later patches.\n> > \n> > The SVE architecture permits, but does not require, implementations\n> > to support vector lengths that are not a power of two.  To handle\n> > this, logic is added to check a requested vector length against a\n> > possibly sparse bitmap of available vector lengths at runtime, so\n> > that the best supported value can be chosen.\n> > \n> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>\n> > Cc: Alex Bennée <alex.bennee@linaro.org>\n> \n> Can this be merged with patch 20? It seems to add the PR_ definitions\n> which get actually used later when the prctl interface is added.\n\nThis patch is used both by patch 19 and by patch 20, which I preferred\nnot to merge with each other: ptrace and prctl are significantly\ndifferent things.\n\nThe prctl bit definitions are added here because they are the canonical\ndefinitions used by both interfaces.  The ptrace #defines are based on\nthem.\n\nDoes it make sense if I merge patch 20 into this one and apply patch 19\non top?  This avoide the appearance of prctl #defines with no prctl\nimplementation.\n\nCheers\n---Dave","headers":{"Return-Path":"<libc-alpha-return-84570-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-84570-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=\"ECUrh6IS\"; 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 3xsrjt71tgz9sPk\n\tfor <incoming@patchwork.ozlabs.org>;\n\tThu, 14 Sep 2017 05:06:26 +1000 (AEST)","(qmail 85205 invoked by alias); 13 Sep 2017 19:06:20 -0000","(qmail 85186 invoked by uid 89); 13 Sep 2017 19:06:19 -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=CxrDo6BM/bVXd/ldKIpD0HgQcehgMM\n\tW7cNxvdGExZxuuqjY3Mq/d0+Z06UpaRCq5gbq8KprkV1cFRBP/WMo7woRna8OKqw\n\tNfsD5QVt76qpwRjOj+d1+KXxbF6KoIL4KGpYDQwP2IVB5n0JYZOpGF1VrE/urptu\n\tOixPWnKVA0Tgs=","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=q/vEXNdPEqdQvSsVfCsdzwKMf+c=; b=ECUr\n\th6IS7D0cA33ufV93RtNfokHI/chiUOxyJiImQ0rnVe4Oip5/FjrQv4BG6PaBUfR1\n\ty9UPoXBnoSYq2TM2uzxsWdfEzmN6cmDi/Rjud/uqjCghY3ANmyx0cof8jzE/PRZR\n\tHqeN8mthvCm3mtSUBkClFqu54dqfViVRA3oYOL4=","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,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1463","X-Spam-User":"qpsmtpd, 2 recipients","X-HELO":"foss.arm.com","Date":"Wed, 13 Sep 2017 20:06:12 +0100","From":"Dave Martin <Dave.Martin@arm.com>","To":"Catalin Marinas <catalin.marinas@arm.com>","Cc":"linux-arch@vger.kernel.org, libc-alpha@sourceware.org, Ard Biesheuvel\n\t<ard.biesheuvel@linaro.org>, \tSzabolcs Nagy <szabolcs.nagy@arm.com>,\n\tRichard Sandiford <richard.sandiford@arm.com>, Yao Qi <Yao.Qi@arm.com>,\n\tAlan Hayward <alan.hayward@arm.com>, Will Deacon <will.deacon@arm.com>,\n\tgdb@sourceware.org, Alex =?iso-8859-1?q?Benn=E9e?=\n\t<alex.bennee@linaro.org>, kvmarm@lists.cs.columbia.edu,\n\tlinux-arm-kernel@lists.infradead.org","Subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","Message-ID":"<20170913190611.GC23415@e103592.cambridge.arm.com>","References":"<1504198860-12951-1-git-send-email-Dave.Martin@arm.com>\n\t<1504198860-12951-15-git-send-email-Dave.Martin@arm.com>\n\t<20170913172911.3ca2h6cpju7etifi@localhost>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20170913172911.3ca2h6cpju7etifi@localhost>","User-Agent":"Mutt/1.5.23 (2014-03-12)"}},{"id":1768220,"web_url":"http://patchwork.ozlabs.org/comment/1768220/","msgid":"<20170913221123.y4znytmxtplx24m4@localhost>","list_archive_url":null,"date":"2017-09-13T22:11:23","subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","submitter":{"id":938,"url":"http://patchwork.ozlabs.org/api/people/938/","name":"Catalin Marinas","email":"catalin.marinas@arm.com"},"content":"On Wed, Sep 13, 2017 at 08:06:12PM +0100, Dave P Martin wrote:\n> On Wed, Sep 13, 2017 at 10:29:11AM -0700, Catalin Marinas wrote:\n> > On Thu, Aug 31, 2017 at 06:00:46PM +0100, Dave P Martin wrote:\n> > > This patch implements the core logic for changing a task's vector\n> > > length on request from userspace.  This will be used by the ptrace\n> > > and prctl frontends that are implemented in later patches.\n> > > \n> > > The SVE architecture permits, but does not require, implementations\n> > > to support vector lengths that are not a power of two.  To handle\n> > > this, logic is added to check a requested vector length against a\n> > > possibly sparse bitmap of available vector lengths at runtime, so\n> > > that the best supported value can be chosen.\n> > > \n> > > Signed-off-by: Dave Martin <Dave.Martin@arm.com>\n> > > Cc: Alex Bennée <alex.bennee@linaro.org>\n> > \n> > Can this be merged with patch 20? It seems to add the PR_ definitions\n> > which get actually used later when the prctl interface is added.\n> \n> This patch is used both by patch 19 and by patch 20, which I preferred\n> not to merge with each other: ptrace and prctl are significantly\n> different things.\n> \n> The prctl bit definitions are added here because they are the canonical\n> definitions used by both interfaces.  The ptrace #defines are based on\n> them.\n> \n> Does it make sense if I merge patch 20 into this one and apply patch 19\n> on top?  This avoide the appearance of prctl #defines with no prctl\n> implementation.\n\nThat's fine, you can bring patch 20 forward. If there are other\nnon-trivial issues, feel free to ignore my comment.","headers":{"Return-Path":"<libc-alpha-return-84579-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-84579-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=\"vFNEDppL\"; 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 3xswqq6kfJz9sRg\n\tfor <incoming@patchwork.ozlabs.org>;\n\tThu, 14 Sep 2017 08:11:51 +1000 (AEST)","(qmail 88225 invoked by alias); 13 Sep 2017 22:11:28 -0000","(qmail 88196 invoked by uid 89); 13 Sep 2017 22:11:28 -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=SC70TJ9H0hf73ruIoO+2BI2r9M3Qia\n\t8LU51ujm0Jv7qrhkAC02NCH0GVd74eWgomF6qpO2vD5yeOrwroGCfrO51RCd6Q/x\n\tXfSCrssh4se608xLCv5eY8vdqjK9hjE0tsz/rvylVLUDyWmvQ5p0nOhzEOZOxMz5\n\tNQWQFuCmD2KXU=","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=m4ruXJ/5RviSpHUftiQogEiqlSI=; b=vFNE\n\tDppLoR1mMxL1MazTqXQKcC1/sMkiULkmZUN1XPnAZFbEhFUxruYhKpN0km3lKnEC\n\t19WGNNESM0UKGehgr4GmfumWhzhMRr1xrOrjeuTWELGgjXNRC0XcmTdJiSrYgeI2\n\tpVYPAulzUT2SloQYtwV1TClPERP+BUYFFgCKRMQ=","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,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1694","X-Spam-User":"qpsmtpd, 2 recipients","X-HELO":"foss.arm.com","Date":"Wed, 13 Sep 2017 15:11:23 -0700","From":"Catalin Marinas <catalin.marinas@arm.com>","To":"Dave Martin <Dave.Martin@arm.com>","Cc":"linux-arch@vger.kernel.org, libc-alpha@sourceware.org,\n\tgdb@sourceware.org, Ard Biesheuvel <ard.biesheuvel@linaro.org>,\n\tSzabolcs Nagy <szabolcs.nagy@arm.com>, Richard Sandiford\n\t<richard.sandiford@arm.com>, Yao Qi <Yao.Qi@arm.com>,\n\tWill Deacon <will.deacon@arm.com>, Alan Hayward <alan.hayward@arm.com>,\n\tAlex =?iso-8859-1?q?Benn=E9e?= <alex.bennee@linaro.org>,\n\tkvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org","Subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","Message-ID":"<20170913221123.y4znytmxtplx24m4@localhost>","References":"<1504198860-12951-1-git-send-email-Dave.Martin@arm.com>\n\t<1504198860-12951-15-git-send-email-Dave.Martin@arm.com>\n\t<20170913172911.3ca2h6cpju7etifi@localhost>\n\t<20170913190611.GC23415@e103592.cambridge.arm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20170913190611.GC23415@e103592.cambridge.arm.com>","User-Agent":"NeoMutt/20170113 (1.7.2)"}},{"id":1771736,"web_url":"http://patchwork.ozlabs.org/comment/1771736/","msgid":"<FC5BA359-D37C-493C-87CD-146B83D3CCB5@arm.com>","list_archive_url":null,"date":"2017-09-20T10:59:55","subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","submitter":{"id":65004,"url":"http://patchwork.ozlabs.org/api/people/65004/","name":"Alan Hayward","email":"alan.hayward@arm.com"},"content":"(Resending without disclaimer)\r\n\r\n> On 31 Aug 2017, at 18:00, Dave Martin <Dave.Martin@arm.com> wrote:\r\n\r\n> \r\n> +int sve_set_vector_length(struct task_struct *task,\r\n> +\t\t\t  unsigned long vl, unsigned long flags)\r\n> +{\r\n> +\tWARN_ON(task == current && preemptible());\r\n> +\r\n> +\tif (flags & ~(unsigned long)(PR_SVE_VL_INHERIT |\r\n> +\t\t\t\t     PR_SVE_SET_VL_ONEXEC))\r\n> +\t\treturn -EINVAL;\r\n> +\r\n> +\tif (!sve_vl_valid(vl))\r\n> +\t\treturn -EINVAL;\r\n> +\r\n> +\t/*\r\n> +\t * Clamp to the maximum vector length that VL-agnostic SVE code can\r\n> +\t * work with.  A flag may be assigned in the future to allow setting\r\n> +\t * of larger vector lengths without confusing older software.\r\n> +\t */\r\n> +\tif (vl > SVE_VL_ARCH_MAX)\r\n> +\t\tvl = SVE_VL_ARCH_MAX;\r\n> +\r\n> +\tvl = find_supported_vector_length(vl);\r\n> +\r\n\r\n\r\nGiven, sve_set_vector_length is called when setting the vector length in\r\nPTRACE_SETREGSET, it looks to me like if you set VL to a value that’s not\r\nsupported by the hardware, then it’s going to round down to the previous value.\r\nIs that correct? I’m not sure if that’s explained in the docs?\r\n\r\nWhat happens if you give a vl value lower than the min supported value in the\r\nhardware?\r\n\r\n\r\n> +/*\r\n> + * All vector length selection from userspace comes through here.\r\n> + * We're on a slow path, so some sanity-checks are included.\r\n> + * If things go wrong there's a bug somewhere, but try to fall back to a\r\n> + * safe choice.\r\n> + */\r\n> +static unsigned int find_supported_vector_length(unsigned int vl)\r\n> +{\r\n> +\tint bit;\r\n> +\tint max_vl = sve_max_vl;\r\n> +\r\n> +\tif (WARN_ON(!sve_vl_valid(vl)))\r\n> +\t\tvl = SVE_VL_MIN;\r\n> +\r\n> +\tif (WARN_ON(!sve_vl_valid(max_vl)))\r\n> +\t\tmax_vl = SVE_VL_MIN;\r\n> +\r\n> +\tif (vl > max_vl)\r\n> +\t\tvl = max_vl;\r\n> +\r\n> +\tbit = find_next_bit(sve_vq_map, SVE_VQ_MAX,\r\n> +\t\t\t    vq_to_bit(sve_vq_from_vl(vl)));\r\n> +\treturn sve_vl_from_vq(bit_to_vq(bit));\r\n> +}\r\n> +\r\n\r\n\r\nThanks,\r\nAlan.","headers":{"Return-Path":"<libc-alpha-return-84775-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-84775-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=\"srjrArj7\"; dkim-atps=neutral","sourceware.org; auth=none","spf=none (sender IP is )\n\tsmtp.mailfrom=Alan.Hayward@arm.com; "],"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 3xxxbl5tNxz9sPt\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed, 20 Sep 2017 21:00:19 +1000 (AEST)","(qmail 99560 invoked by alias); 20 Sep 2017 11:00:03 -0000","(qmail 96425 invoked by uid 89); 20 Sep 2017 11:00:01 -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:references\n\t:in-reply-to:content-type:content-id:content-transfer-encoding\n\t:mime-version; q=dns; s=default; b=glxy5nhzos3sLDsR0lzthgCfVotNR\n\tx/B5HJ41TFNE8HF+9NgF0fouhBso9+xN/mqnGx+S/67sGBVRgzg4bfIj7lzOHN2b\n\tW9toEh/El4nTlLfqJhW3399JzKzybtJdfdj+nYZg8/uE2QW0IWIOjbZ35+kuhSON\n\tSv3vOP58c3td4w=","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:references\n\t:in-reply-to:content-type:content-id:content-transfer-encoding\n\t:mime-version; s=default; bh=oWWRNRJNGug866FpSVt/urT0xME=; b=srj\n\trArj7U5TguTUzPSeZ2ACjUumh5GSJK5EjQ+dUS+/mamq18/RXz9Db4mrgHZw6Mjv\n\tZ67W4vW/9t/a6CbsjaPEjZU1AwwjeRSHmTDg4pEbPBW7Mh3NlE2VyMFqqpzYgSxD\n\tuSdpi34JrEoUCDGAUrFszwcvBybtNgdzCw4ka1XQ=","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=-3.5 required=5.0 tests=AWL, BAYES_00,\n\tMIME_BASE64_BLANKS, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1890,\n\tHAccept-Language:en-GB","X-Spam-User":"qpsmtpd, 2 recipients","X-HELO":"EUR01-HE1-obe.outbound.protection.outlook.com","From":"Alan Hayward <Alan.Hayward@arm.com>","To":"Dave P Martin <Dave.Martin@arm.com>","CC":"\"linux-arm-kernel@lists.infradead.org\"\n\t<linux-arm-kernel@lists.infradead.org>, Catalin Marinas\n\t<Catalin.Marinas@arm.com>, Will Deacon <Will.Deacon@arm.com>,\n\tArd Biesheuvel <ard.biesheuvel@linaro.org>, =?utf-8?q?Alex_Benn=C3=A9?=\n\t=?utf-8?q?e?= <alex.bennee@linaro.org>,\n\tSzabolcs Nagy <Szabolcs.Nagy@arm.com>, \"Richard Sandiford\"\n\t<Richard.Sandiford@arm.com>, \"kvmarm@lists.cs.columbia.edu\"\n\t<kvmarm@lists.cs.columbia.edu>, \"libc-alpha@sourceware.org\"\n\t<libc-alpha@sourceware.org>, \"linux-arch@vger.kernel.org\"\n\t<linux-arch@vger.kernel.org>,\n\t\"gdb@sourceware.org\" <gdb@sourceware.org>, \"Yao Qi\" <Yao.Qi@arm.com>,\n\tnd <nd@arm.com>","Subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","Date":"Wed, 20 Sep 2017 10:59:55 +0000","Message-ID":"<FC5BA359-D37C-493C-87CD-146B83D3CCB5@arm.com>","References":"<1504198860-12951-1-git-send-email-Dave.Martin@arm.com>\n\t<1504198860-12951-15-git-send-email-Dave.Martin@arm.com>","In-Reply-To":"<1504198860-12951-15-git-send-email-Dave.Martin@arm.com>","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-84775-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=\"srjrArj7\"; dkim-atps=neutral","sourceware.org; auth=none","spf=none (sender IP is )\n\tsmtp.mailfrom=Alan.Hayward@arm.com; "],"x-ms-publictraffictype":"Email","x-microsoft-exchange-diagnostics":"1; AM3PR08MB0166;\n\t6:xcNdcj4GfeGn4lp+/qz81028oMDHHJ1BSM4PiUe/6uraIhRvAnC7KYbP6qSClIr5u/NGvQNlbseKsSurQNLVD7OdQnq9Znw+IRFJXR8QXERHUhzuvLVCIRBHIhxKGM/R4CIQ2JKE7S13qx99iMPLmj20wiHG3UF9y8eoThwwOPqPrAF9bF4vchTewFRJoIVEoaCcsQujKXxjgH7r8CsapsaFjrwu0UpzqNjKaTlCWh8JA0iXx5Wx+mwYPec+EKpjD1hN5DXRNXydK4bJ3NMugbyLtCLYhqnpMeYzKzrX4dCZ49iJ3JAoaQLPPcztcduPcsJNBcDAD8XX8mq9tFGOlw==;\n\t5:zs4z02AvNY8cGWwPselDc/qpaHLDvdCc7KNAAjfNpAn9W7QdKQismnYM7H4LhLIypdBgNHjaRWnH12pPw3/lvgG9gYii+MJFynUPbflrbLFm6rhuYJeEH7L7l9KEGvkb519ayYCaep54SMaHemFyJw==;\n\t24:63MLlhR+BNArWjYPLaO4vR/Om8UGCqDB/sC1MM7cNvMiXbsQJPeTY0yp6283qOHqv/I9OUOn3X5DKcGIC3ZM+sGtft37M3y23oHkyZwhsEE=;\n\t7:zJrmOAWOyPp9IfRdKsiY7zIQ9KqcoIwOjt/VdP5dCFult8QQprhE9F/SGCUZV7ie4Py02S0bDlmR2G26lERX8PbvH4NztkrBH2pKxqaaxHg3TsvT1K8yzcH8POBqlDqn5HudTv4iF/SLVM1GGM/fmgLwAOE9Z4xroWtcLPoAha16PKmxqMA9tJTuWsReLZOFsRMKy4hoTL517+OsB3imp9uHY8lKS7BJHu7ygQf1G3U=","x-ms-exchange-antispam-srfa-diagnostics":"SSOS;","x-ms-office365-filtering-correlation-id":"a9531a05-b192-4357-f491-08d50016ba63","x-ms-office365-filtering-ht":"Tenant","x-microsoft-antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);\n\tSRVR:AM3PR08MB0166; ","x-ms-traffictypediagnostic":"AM3PR08MB0166:","nodisclaimer":"True","x-exchange-antispam-report-test":"UriScan:(180628864354917);","x-microsoft-antispam-prvs":"<AM3PR08MB016673535C86D45B3FAB176B97610@AM3PR08MB0166.eurprd08.prod.outlook.com>","x-exchange-antispam-report-cfa-test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:AM3PR08MB0166; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:AM3PR08MB0166; ","x-forefront-prvs":"04362AC73B","x-forefront-antispam-report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(39860400002)(346002)(376002)(189002)(199003)(24454002)(229853002)(6436002)(54906003)(6506006)(82746002)(36756003)(316002)(8676002)(81156014)(81166006)(37006003)(53546010)(7736002)(5250100002)(305945005)(6486002)(101416001)(6862004)(5660300001)(68736007)(189998001)(2906002)(4326008)(86362001)(3280700002)(3660700001)(8936002)(50986999)(76176999)(54356999)(478600001)(2900100001)(97736004)(72206003)(66066001)(6246003)(25786009)(14454004)(83716003)(6512007)(105586002)(6116002)(106356001)(2950100002)(6636002)(53936002)(102836003)(3846002)(33656002)(99286003);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR08MB0166;\n\tH:AM3PR08MB0101.eurprd08.prod.outlook.com; FPR:; SPF:None;\n\tPTR:InfoNoRecords; MX:1; A:1; LANG:en; ","received-spf":"None (protection.outlook.com: arm.com does not designate\n\tpermitted sender hosts)","spamdiagnosticoutput":"1:99","spamdiagnosticmetadata":"NSPM","Content-Type":"text/plain; charset=\"utf-8\"","Content-ID":"<6B3111D0F66877459DFF3822341B37B7@eurprd08.prod.outlook.com>","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","X-OriginatorOrg":"arm.com","X-MS-Exchange-CrossTenant-originalarrivaltime":"20 Sep 2017 10:59:55.8092\n\t(UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"f34e5979-57d9-4aaa-ad4d-b122a662184d","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"AM3PR08MB0166"}},{"id":1771741,"web_url":"http://patchwork.ozlabs.org/comment/1771741/","msgid":"<20170920110902.GG24231@e103592.cambridge.arm.com>","list_archive_url":null,"date":"2017-09-20T11:09:04","subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","submitter":{"id":72402,"url":"http://patchwork.ozlabs.org/api/people/72402/","name":"Dave Martin","email":"dave.martin@foss.arm.com"},"content":"On Wed, Sep 20, 2017 at 10:59:55AM +0000, Alan Hayward wrote:\n> (Resending without disclaimer)\n> \n> > On 31 Aug 2017, at 18:00, Dave Martin <Dave.Martin@arm.com> wrote:\n> \n> > \n> > +int sve_set_vector_length(struct task_struct *task,\n> > +\t\t\t  unsigned long vl, unsigned long flags)\n> > +{\n> > +\tWARN_ON(task == current && preemptible());\n> > +\n> > +\tif (flags & ~(unsigned long)(PR_SVE_VL_INHERIT |\n> > +\t\t\t\t     PR_SVE_SET_VL_ONEXEC))\n> > +\t\treturn -EINVAL;\n> > +\n> > +\tif (!sve_vl_valid(vl))\n> > +\t\treturn -EINVAL;\n> > +\n> > +\t/*\n> > +\t * Clamp to the maximum vector length that VL-agnostic SVE code can\n> > +\t * work with.  A flag may be assigned in the future to allow setting\n> > +\t * of larger vector lengths without confusing older software.\n> > +\t */\n> > +\tif (vl > SVE_VL_ARCH_MAX)\n> > +\t\tvl = SVE_VL_ARCH_MAX;\n> > +\n> > +\tvl = find_supported_vector_length(vl);\n> > +\n> \n> \n> Given, sve_set_vector_length is called when setting the vector length in\n> PTRACE_SETREGSET, it looks to me like if you set VL to a value that’s not\n> supported by the hardware, then it’s going to round down to the previous value.\n> Is that correct? I’m not sure if that’s explained in the docs?\n\nDoes this cover it?\n\n\"On success, the calling thread's vector length is changed to the\nlargest value supported by the system that is less than or equal to vl.\"\n\n(For ptrace, I just cross-reference the PR_SVE_SET_VL behaviour, above.)\n\n> What happens if you give a vl value lower than the min supported value in the\n> hardware?\n\nThis is impossible, unless vl < SVE_VL_MIN (which is rejected explicitly\nby the !sve_vl_valid() check in sve_set_vector_length()).\n\nThe architecture required support for all power-of-two vector lengths\nless than the maximum supported vector length, so by construction\nSVE_VL_MIN is supported by all hardware.\n\nTo be defensive, if we fail to detect support for SVE_VL_MIN, I set the\ncorresponding bit in sve_vq_map and WARN.  This is just to help ensure\nfind_supported_vector_length doesn't fall off the end of sve_vq_map.\n\n\nDoes that sounds correct?  There may be a clearer way of achieving this.\n\nCheers\n---Dave\n\n> \n> \n> > +/*\n> > + * All vector length selection from userspace comes through here.\n> > + * We're on a slow path, so some sanity-checks are included.\n> > + * If things go wrong there's a bug somewhere, but try to fall back to a\n> > + * safe choice.\n> > + */\n> > +static unsigned int find_supported_vector_length(unsigned int vl)\n> > +{\n> > +\tint bit;\n> > +\tint max_vl = sve_max_vl;\n> > +\n> > +\tif (WARN_ON(!sve_vl_valid(vl)))\n> > +\t\tvl = SVE_VL_MIN;\n> > +\n> > +\tif (WARN_ON(!sve_vl_valid(max_vl)))\n> > +\t\tmax_vl = SVE_VL_MIN;\n> > +\n> > +\tif (vl > max_vl)\n> > +\t\tvl = max_vl;\n> > +\n> > +\tbit = find_next_bit(sve_vq_map, SVE_VQ_MAX,\n> > +\t\t\t    vq_to_bit(sve_vq_from_vl(vl)));\n> > +\treturn sve_vl_from_vq(bit_to_vq(bit));\n> > +}\n> > +\n> \n> \n> Thanks,\n> Alan.\n> _______________________________________________\n> linux-arm-kernel mailing list\n> linux-arm-kernel@lists.infradead.org\n> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel","headers":{"Return-Path":"<libc-alpha-return-84776-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-84776-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=\"ZpOcE6Pv\"; 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 3xxxpD6fPWz9s7f\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed, 20 Sep 2017 21:09:24 +1000 (AEST)","(qmail 21017 invoked by alias); 20 Sep 2017 11:09:13 -0000","(qmail 20914 invoked by uid 89); 20 Sep 2017 11:09:12 -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=IDi4zIUstsocYxGODN1b5wLNwisTTg\n\t65ACpyVB2XQVDqfDq8KrtZzLxp834Kvz9S/EMuupaBOpTvRHf7OM61sAzBmBdTBE\n\tyCXCiyRlpMZO4GHa3Pum8tq2z3D+e5Mz5HD77n9SpsgZT9mJf93pe4xL/Q+GSU/l\n\t0LoTvwl2HbqYk=","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=ui8p9UWbxgEzoq5bk7tUHsEwKEg=; b=ZpOc\n\tE6PvRr277zQ+b+giP0xWyA2E+UgTSUHVWBH58/PGwpi26f74MPYy5R37fd45Fg5B\n\tY46WRZ1e+Q/YS28brLOTBExFJtaEn1h0eJNw+h+cUA88rDYZlf06caTvCw1LINgd\n\ty3iYRqGAHMfwqj+nIE2g7hlUkEGG65JKlPo1h5k=","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,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=disclaimer","X-Spam-User":"qpsmtpd, 2 recipients","X-HELO":"foss.arm.com","Date":"Wed, 20 Sep 2017 12:09:04 +0100","From":"Dave Martin <dave.martin@foss.arm.com>","To":"Alan Hayward <Alan.Hayward@arm.com>","Cc":"Dave P Martin <Dave.Martin@arm.com>, \"linux-arch@vger.kernel.org\"\n\t<linux-arch@vger.kernel.org>, \"libc-alpha@sourceware.org\"\n\t<libc-alpha@sourceware.org>, \"gdb@sourceware.org\" <gdb@sourceware.org>, \n\tArd Biesheuvel <ard.biesheuvel@linaro.org>, \n\tSzabolcs Nagy <Szabolcs.Nagy@arm.com>, Catalin Marinas\n\t<Catalin.Marinas@arm.com>, Yao Qi <Yao.Qi@arm.com>, Will Deacon\n\t<Will.Deacon@arm.com>, Richard Sandiford <Richard.Sandiford@arm.com>,\n\tnd <nd@arm.com>, Alex =?iso-8859-1?q?Benn=E9e?= <alex.bennee@linaro.org>,\n\t\"kvmarm@lists.cs.columbia.edu\" <kvmarm@lists.cs.columbia.edu>, \n\t\"linux-arm-kernel@lists.infradead.org\"\n\t<linux-arm-kernel@lists.infradead.org>","Subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","Message-ID":"<20170920110902.GG24231@e103592.cambridge.arm.com>","References":"<1504198860-12951-1-git-send-email-Dave.Martin@arm.com>\n\t<1504198860-12951-15-git-send-email-Dave.Martin@arm.com>\n\t<FC5BA359-D37C-493C-87CD-146B83D3CCB5@arm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<FC5BA359-D37C-493C-87CD-146B83D3CCB5@arm.com>","User-Agent":"Mutt/1.5.23 (2014-03-12)"}},{"id":1772135,"web_url":"http://patchwork.ozlabs.org/comment/1772135/","msgid":"<E82895B2-3F95-4A54-8703-D654221F8CBA@arm.com>","list_archive_url":null,"date":"2017-09-20T18:08:21","subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","submitter":{"id":65004,"url":"http://patchwork.ozlabs.org/api/people/65004/","name":"Alan Hayward","email":"alan.hayward@arm.com"},"content":"> On 20 Sep 2017, at 12:09, Dave Martin <dave.martin@foss.arm.com> wrote:\r\n> \r\n> On Wed, Sep 20, 2017 at 10:59:55AM +0000, Alan Hayward wrote:\r\n>> (Resending without disclaimer)\r\n>> \r\n>>> On 31 Aug 2017, at 18:00, Dave Martin <Dave.Martin@arm.com> wrote:\r\n>> \r\n>>> \r\n>>> +int sve_set_vector_length(struct task_struct *task,\r\n>>> +\t\t\t  unsigned long vl, unsigned long flags)\r\n>>> +{\r\n>>> +\tWARN_ON(task == current && preemptible());\r\n>>> +\r\n>>> +\tif (flags & ~(unsigned long)(PR_SVE_VL_INHERIT |\r\n>>> +\t\t\t\t     PR_SVE_SET_VL_ONEXEC))\r\n>>> +\t\treturn -EINVAL;\r\n>>> +\r\n>>> +\tif (!sve_vl_valid(vl))\r\n>>> +\t\treturn -EINVAL;\r\n>>> +\r\n>>> +\t/*\r\n>>> +\t * Clamp to the maximum vector length that VL-agnostic SVE code can\r\n>>> +\t * work with.  A flag may be assigned in the future to allow setting\r\n>>> +\t * of larger vector lengths without confusing older software.\r\n>>> +\t */\r\n>>> +\tif (vl > SVE_VL_ARCH_MAX)\r\n>>> +\t\tvl = SVE_VL_ARCH_MAX;\r\n>>> +\r\n>>> +\tvl = find_supported_vector_length(vl);\r\n>>> +\r\n>> \r\n>> \r\n>> Given, sve_set_vector_length is called when setting the vector length in\r\n>> PTRACE_SETREGSET, it looks to me like if you set VL to a value that’s not\r\n>> supported by the hardware, then it’s going to round down to the previous value.\r\n>> Is that correct? I’m not sure if that’s explained in the docs?\r\n> \r\n> Does this cover it?\r\n> \r\n> \"On success, the calling thread's vector length is changed to the\r\n> largest value supported by the system that is less than or equal to vl.\"\r\n> \r\n> (For ptrace, I just cross-reference the PR_SVE_SET_VL behaviour, above.)\r\n\r\nFor ptrace is it worth mentioning user should do a GET after a SET to confirm\r\nwhat VL value was actually set?\r\n\r\n> \r\n>> What happens if you give a vl value lower than the min supported value in the\r\n>> hardware?\r\n> \r\n> This is impossible, unless vl < SVE_VL_MIN (which is rejected explicitly\r\n> by the !sve_vl_valid() check in sve_set_vector_length()).\r\n> \r\n> The architecture required support for all power-of-two vector lengths\r\n> less than the maximum supported vector length, so by construction\r\n> SVE_VL_MIN is supported by all hardware.\r\n\r\nOk, I’m happy with that.\r\n\r\n> \r\n> To be defensive, if we fail to detect support for SVE_VL_MIN, I set the\r\n> corresponding bit in sve_vq_map and WARN.  This is just to help ensure\r\n> find_supported_vector_length doesn't fall off the end of sve_vq_map.\r\n> \r\n> \r\n> Does that sounds correct?  There may be a clearer way of achieving this.\r\n> \r\n> Cheers\r\n> ---Dave\r\n> \r\n>> \r\n>> \r\n>>> +/*\r\n>>> + * All vector length selection from userspace comes through here.\r\n>>> + * We're on a slow path, so some sanity-checks are included.\r\n>>> + * If things go wrong there's a bug somewhere, but try to fall back to a\r\n>>> + * safe choice.\r\n>>> + */\r\n>>> +static unsigned int find_supported_vector_length(unsigned int vl)\r\n>>> +{\r\n>>> +\tint bit;\r\n>>> +\tint max_vl = sve_max_vl;\r\n>>> +\r\n>>> +\tif (WARN_ON(!sve_vl_valid(vl)))\r\n>>> +\t\tvl = SVE_VL_MIN;\r\n>>> +\r\n>>> +\tif (WARN_ON(!sve_vl_valid(max_vl)))\r\n>>> +\t\tmax_vl = SVE_VL_MIN;\r\n>>> +\r\n>>> +\tif (vl > max_vl)\r\n>>> +\t\tvl = max_vl;\r\n>>> +\r\n>>> +\tbit = find_next_bit(sve_vq_map, SVE_VQ_MAX,\r\n>>> +\t\t\t    vq_to_bit(sve_vq_from_vl(vl)));\r\n>>> +\treturn sve_vl_from_vq(bit_to_vq(bit));\r\n>>> +}\r\n>>> +\r\n>> \r\n>> \r\n>> Thanks,\r\n>> Alan.\r\n>> _______________________________________________\r\n>> linux-arm-kernel mailing list\r\n>> linux-arm-kernel@lists.infradead.org\r\n>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel","headers":{"Return-Path":"<libc-alpha-return-84795-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-84795-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=\"MvRpXb/h\"; dkim-atps=neutral","sourceware.org; auth=none","spf=none (sender IP is )\n\tsmtp.mailfrom=Alan.Hayward@arm.com; "],"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 3xy76N576tz9s8J\n\tfor <incoming@patchwork.ozlabs.org>;\n\tThu, 21 Sep 2017 04:09:00 +1000 (AEST)","(qmail 122703 invoked by alias); 20 Sep 2017 18:08:28 -0000","(qmail 122625 invoked by uid 89); 20 Sep 2017 18:08:28 -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:references\n\t:in-reply-to:content-type:content-id:content-transfer-encoding\n\t:mime-version; q=dns; s=default; b=omXh5+XNo/Ah8SWuqzzP0BZxc85SF\n\tc74gWpDpg4xIV0nWHA11RMpSkQKZG8RKIm136fsa/vAC7aGkVAU+BW7gpqTJnFVN\n\tpk+aQUH1+XDUvZwc0uWMkwGTLQPW8e3Gr2XI9pp4DNzEaFQuQ53gNYp2WSlA5i4V\n\tONQK1DQx8T0ml0=","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:references\n\t:in-reply-to:content-type:content-id:content-transfer-encoding\n\t:mime-version; s=default; bh=w/1E38LWXcUh32v55uIZuxiJYAo=; b=MvR\n\tpXb/hRtFirBS7OunDSBaHCIpJgM51f3BirD0AI4Ga23iqF9PoftBAT3OgOrTHfk8\n\tuJ347YdqjQBoYCO2dBK6fskCDajSULXNqUZXWXPR1abW9+zuXwoxM2PkTV3e+clE\n\tf7DZ2Qm7kbyiR+7bE42piRsV/9pD1qKZFvkAh3bc=","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=-3.4 required=5.0 tests=AWL, BAYES_00,\n\tMIME_BASE64_BLANKS, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=","X-Spam-User":"qpsmtpd, 2 recipients","X-HELO":"EUR02-AM5-obe.outbound.protection.outlook.com","From":"Alan Hayward <Alan.Hayward@arm.com>","To":"Dave Martin <dave.martin@foss.arm.com>","CC":"Dave P Martin <Dave.Martin@arm.com>, \"linux-arch@vger.kernel.org\"\n\t<linux-arch@vger.kernel.org>, \"libc-alpha@sourceware.org\"\n\t<libc-alpha@sourceware.org>,\n\t\"gdb@sourceware.org\" <gdb@sourceware.org>, \"Ard Biesheuvel\"\n\t<ard.biesheuvel@linaro.org>, Szabolcs Nagy <Szabolcs.Nagy@arm.com>,\n\tCatalin Marinas <Catalin.Marinas@arm.com>, Yao Qi <Yao.Qi@arm.com>,\n\tWill Deacon <Will.Deacon@arm.com>,\n\tRichard Sandiford <Richard.Sandiford@arm.com>, nd <nd@arm.com>,\n\t=?utf-8?q?Alex_Benn=C3=A9e?= <alex.bennee@linaro.org>,\n\t\"kvmarm@lists.cs.columbia.edu\" <kvmarm@lists.cs.columbia.edu>,\n\t\"linux-arm-kernel@lists.infradead.org\"\n\t<linux-arm-kernel@lists.infradead.org>","Subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","Date":"Wed, 20 Sep 2017 18:08:21 +0000","Message-ID":"<E82895B2-3F95-4A54-8703-D654221F8CBA@arm.com>","References":"<1504198860-12951-1-git-send-email-Dave.Martin@arm.com>\n\t<1504198860-12951-15-git-send-email-Dave.Martin@arm.com>\n\t<FC5BA359-D37C-493C-87CD-146B83D3CCB5@arm.com>\n\t<20170920110902.GG24231@e103592.cambridge.arm.com>","In-Reply-To":"<20170920110902.GG24231@e103592.cambridge.arm.com>","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-84795-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=\"MvRpXb/h\"; dkim-atps=neutral","sourceware.org; auth=none","spf=none (sender IP is )\n\tsmtp.mailfrom=Alan.Hayward@arm.com; "],"x-ms-publictraffictype":"Email","x-microsoft-exchange-diagnostics":"1; AM3PR08MB0708;\n\t6:M+lvd3PYDg53KyuXWW5RElj/4fnCoDuP7Qr6BjzmiKns/mDqhCmhoL4OCMb5X44ED7ZuajYI42uMqfKq99RO/bYYzCVnuFzP5MXdskfJw32saaVTwIhTpFBYKB2kkeTn6a3O661tRNO76WflASKOHxNoKYrMETrFpBHpN7v548zu6jUfVUhnwZqVkAiY+vscZnE7pAe5ghTneNY3/VVjBjKClnzgzOtiileTu28BnT814FBak1qfdEM8rjtJHDBiIB0GaFpPuHORg6GDmxsdVbLcnDvVO6laKjIp0+PbpTw/iyi+KLBrWXo5tEdMNTueoM76kVwDmtXhCzeSOBV9kg==;\n\t5:/Rut767rX1k+lBgStvMar+ZC8ZfX6CYQO+8O7ZVQIiehIpH9l6kbV+oUkgyIBTkcn2jwEoLDysk8LfDZBNqyfecfOq5LiCj+9I9DGfuANbRf6a5zW20kxXDQXO5DEEexK3ftbKEWaip2LZXgz1s+QQ==;\n\t24:tq6m3fnBi+ah0hN1ylCnsuz1GVxA5lvJXPt6PFliKvD6Vn46KeldX3mnf2BB/vRUsbbJKOeryFokmVZKtFalUw9EIzRbiE75DR8keAq8HQw=;\n\t7:nrsu5sCoQV1b5lDHo53MAhuhI9tchvdaC/YvrSv9J/DBmV/oXm3CByDGJ7Ye7QOvNgjJBcbp0tcW6g4g9HBmUkk9a28d0ErCvTwJ8P+NnkRgMPXqGA7e3t1ARZ8kYFfq4wQ/iy6KKE2Oi6vJa3c95pIsdR9Z6sNUOzUBxEP+sPNy/BSmsJir33jKOg/4PmZd6MPwRtUEnlog4ZOOw51K5u9wtnjfkep1QSNumvNmwj8=","x-ms-exchange-antispam-srfa-diagnostics":"SSOS;","x-ms-office365-filtering-correlation-id":"ee48ca93-4ecc-4793-877a-08d500529453","x-ms-office365-filtering-ht":"Tenant","x-microsoft-antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);\n\tSRVR:AM3PR08MB0708; ","x-ms-traffictypediagnostic":"AM3PR08MB0708:","nodisclaimer":"True","x-exchange-antispam-report-test":"UriScan:(180628864354917)(258649278758335); ","x-microsoft-antispam-prvs":"<AM3PR08MB07088602FA659F5BA8BDC30F97610@AM3PR08MB0708.eurprd08.prod.outlook.com>","x-exchange-antispam-report-cfa-test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:AM3PR08MB0708; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:AM3PR08MB0708; ","x-forefront-prvs":"04362AC73B","x-forefront-antispam-report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(346002)(376002)(39860400002)(199003)(24454002)(189002)(2950100002)(5250100002)(93886005)(68736007)(4326008)(25786009)(5660300001)(14454004)(33656002)(6246003)(106356001)(72206003)(53546010)(99286003)(6512007)(1720100001)(2900100001)(76176999)(6306002)(54356999)(53936002)(50986999)(105586002)(82746002)(478600001)(6862004)(966005)(101416001)(8936002)(81156014)(6436002)(81166006)(3846002)(102836003)(6116002)(316002)(83716003)(86362001)(8676002)(189998001)(2906002)(66066001)(6486002)(36756003)(7736002)(305945005)(3660700001)(97736004)(6506006)(54906003)(229853002)(3280700002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR08MB0708;\n\tH:AM3PR08MB0101.eurprd08.prod.outlook.com; FPR:; SPF:None;\n\tPTR:InfoNoRecords; A:1; MX:1; LANG:en; ","received-spf":"None (protection.outlook.com: arm.com does not designate\n\tpermitted sender hosts)","spamdiagnosticoutput":"1:99","spamdiagnosticmetadata":"NSPM","Content-Type":"text/plain; charset=\"utf-8\"","Content-ID":"<E10FDC6A16F67C418BEF1FD9A3874438@eurprd08.prod.outlook.com>","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","X-OriginatorOrg":"arm.com","X-MS-Exchange-CrossTenant-originalarrivaltime":"20 Sep 2017 18:08:21.6426\n\t(UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"f34e5979-57d9-4aaa-ad4d-b122a662184d","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"AM3PR08MB0708"}},{"id":1772708,"web_url":"http://patchwork.ozlabs.org/comment/1772708/","msgid":"<20170921111937.GA17434@e103592.cambridge.arm.com>","list_archive_url":null,"date":"2017-09-21T11:19:45","subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","submitter":{"id":26612,"url":"http://patchwork.ozlabs.org/api/people/26612/","name":"Dave Martin","email":"Dave.Martin@arm.com"},"content":"On Wed, Sep 20, 2017 at 06:08:21PM +0000, Alan Hayward wrote:\n> \n> > On 20 Sep 2017, at 12:09, Dave Martin <dave.martin@foss.arm.com> wrote:\n\n[...]\n\n> >> Given, sve_set_vector_length is called when setting the vector length in\n> >> PTRACE_SETREGSET, it looks to me like if you set VL to a value that’s not\n> >> supported by the hardware, then it’s going to round down to the previous value.\n> >> Is that correct? I’m not sure if that’s explained in the docs?\n> > \n> > Does this cover it?\n> > \n> > \"On success, the calling thread's vector length is changed to the\n> > largest value supported by the system that is less than or equal to vl.\"\n> > \n> > (For ptrace, I just cross-reference the PR_SVE_SET_VL behaviour, above.)\n> \n> For ptrace is it worth mentioning user should do a GET after a SET to confirm\n> what VL value was actually set?\n\nThis seems worth a clarification -- I'd thought this was already\nmentioned, but it isn't.\n\nHow about:\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\n[...]\n\nCheers\n---Dave","headers":{"Return-Path":"<libc-alpha-return-84810-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-84810-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=\"tsJplgD+\"; 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 3xyZ032pdHz9t3m\n\tfor <incoming@patchwork.ozlabs.org>;\n\tThu, 21 Sep 2017 21:20:03 +1000 (AEST)","(qmail 121209 invoked by alias); 21 Sep 2017 11:19:57 -0000","(qmail 121186 invoked by uid 89); 21 Sep 2017 11:19:55 -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=q4/zYPRY6QO4OeSuq9sBny6mk6/Eaw\n\tlk3OOPdNW4yq5/aYMzxBBtqKGdX3rPB8n+qu9Y4l9UEErQjb8lo/g+WNHf5rWfIj\n\tdEQatYMndUCDZ+gfEc9U1PUB1MFARmKTlAJyYq0Vlon1MQ2nGHO3nvUMVaXLvzwO\n\tJvmUnTX3R2MII=","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=u0xCy31uG6aMKKJPNMlxMgt4P08=; b=tsJp\n\tlgD+ZqHBCGyZDLaxxIqQC0FOQXDOECRywQG4iewTm7sWRz0HbMWk2T72BM1GdlYv\n\tU/K4WAvOyaEBNaIEgPOeF+qwxCdknHFYu11GY7+1AJURMjZbamrGbgvC7zpCtTAb\n\t9pcopG0OMeibDbUgrND9/ZJW58KPm4FsspZ+CcU=","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\n\tspammy=HContent-Transfer-Encoding:8bit","X-Spam-User":"qpsmtpd, 2 recipients","X-HELO":"foss.arm.com","Date":"Thu, 21 Sep 2017 12:19:45 +0100","From":"Dave Martin <Dave.Martin@arm.com>","To":"Alan Hayward <Alan.Hayward@arm.com>","Cc":"Dave Martin <dave.martin@foss.arm.com>, \"linux-arch@vger.kernel.org\"\n\t<linux-arch@vger.kernel.org>, \"libc-alpha@sourceware.org\"\n\t<libc-alpha@sourceware.org>, \"gdb@sourceware.org\" <gdb@sourceware.org>, \n\tArd Biesheuvel <ard.biesheuvel@linaro.org>, \n\tSzabolcs Nagy <Szabolcs.Nagy@arm.com>, Catalin Marinas\n\t<Catalin.Marinas@arm.com>, Yao Qi <Yao.Qi@arm.com>, Will Deacon\n\t<Will.Deacon@arm.com>, Richard Sandiford <Richard.Sandiford@arm.com>,\n\tnd <nd@arm.com>, Alex =?iso-8859-1?q?Benn=E9e?= <alex.bennee@linaro.org>,\n\t\"kvmarm@lists.cs.columbia.edu\" <kvmarm@lists.cs.columbia.edu>, \n\t\"linux-arm-kernel@lists.infradead.org\"\n\t<linux-arm-kernel@lists.infradead.org>","Subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","Message-ID":"<20170921111937.GA17434@e103592.cambridge.arm.com>","References":"<1504198860-12951-1-git-send-email-Dave.Martin@arm.com>\n\t<1504198860-12951-15-git-send-email-Dave.Martin@arm.com>\n\t<FC5BA359-D37C-493C-87CD-146B83D3CCB5@arm.com>\n\t<20170920110902.GG24231@e103592.cambridge.arm.com>\n\t<E82895B2-3F95-4A54-8703-D654221F8CBA@arm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<E82895B2-3F95-4A54-8703-D654221F8CBA@arm.com>","User-Agent":"Mutt/1.5.23 (2014-03-12)"}},{"id":1772739,"web_url":"http://patchwork.ozlabs.org/comment/1772739/","msgid":"<E7AEE685-0814-4308-97D2-4AC095A52ED2@arm.com>","list_archive_url":null,"date":"2017-09-21T11:57:24","subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","submitter":{"id":65004,"url":"http://patchwork.ozlabs.org/api/people/65004/","name":"Alan Hayward","email":"alan.hayward@arm.com"},"content":"> On 21 Sep 2017, at 12:19, Dave Martin <Dave.Martin@arm.com> wrote:\r\n> \r\n> On Wed, Sep 20, 2017 at 06:08:21PM +0000, Alan Hayward wrote:\r\n>> \r\n>>> On 20 Sep 2017, at 12:09, Dave Martin <dave.martin@foss.arm.com> wrote:\r\n> \r\n> [...]\r\n> \r\n>>>> Given, sve_set_vector_length is called when setting the vector length in\r\n>>>> PTRACE_SETREGSET, it looks to me like if you set VL to a value that’s not\r\n>>>> supported by the hardware, then it’s going to round down to the previous value.\r\n>>>> Is that correct? I’m not sure if that’s explained in the docs?\r\n>>> \r\n>>> Does this cover it?\r\n>>> \r\n>>> \"On success, the calling thread's vector length is changed to the\r\n>>> largest value supported by the system that is less than or equal to vl.\"\r\n>>> \r\n>>> (For ptrace, I just cross-reference the PR_SVE_SET_VL behaviour, above.)\r\n>> \r\n>> For ptrace is it worth mentioning user should do a GET after a SET to confirm\r\n>> what VL value was actually set?\r\n> \r\n> This seems worth a clarification -- I'd thought this was already\r\n> mentioned, but it isn't.\r\n> \r\n> How about:\r\n> \r\n>  The caller must make a further GETREGSET call if it needs to know what VL is\r\n>  actually set by SETREGSET, unless is it known in advance that the requested\r\n>  VL is supported.\r\n> \r\n\r\nLooks good to me.\r\n\r\n\r\nAlan.","headers":{"Return-Path":"<libc-alpha-return-84811-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-84811-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=\"T8V8b4sB\"; dkim-atps=neutral","sourceware.org; auth=none","spf=none (sender IP is )\n\tsmtp.mailfrom=Alan.Hayward@arm.com; "],"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 3xyZqN58Zsz9s5L\n\tfor <incoming@patchwork.ozlabs.org>;\n\tThu, 21 Sep 2017 21:57:36 +1000 (AEST)","(qmail 29678 invoked by alias); 21 Sep 2017 11:57:30 -0000","(qmail 29661 invoked by uid 89); 21 Sep 2017 11:57:30 -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:references\n\t:in-reply-to:content-type:content-id:content-transfer-encoding\n\t:mime-version; q=dns; s=default; b=uwstyQGflkbFXhWcXWxHeyT2l3C26\n\tIVsLFLOrvjCXsqymy5hSxG4IsyVqfEd3AaEgkdXmdmhgZ7S/SKj1e7Bbx/9sh2Ao\n\tG6nnAnbbzAi1MDAkTTx9pmFZjOJGpoMRxb68nUavHgr+v4Siwe45hARIUYW0EJU8\n\trjYR9I+qF2bjec=","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:references\n\t:in-reply-to:content-type:content-id:content-transfer-encoding\n\t:mime-version; s=default; bh=ZUa83Owh1D0SAZ/rywQFjHgqIUM=; b=T8V\n\t8b4sBmddvQoBTRdR8YsNagN8ND4owNJm+IPzDTR0DvmS83RFO+DzaQ4/PbpjFCGN\n\tbVNYUrsUrl72aLg/RmY/C/GcvSkir+c4eA1cHoWngQDHF0+e42bK5hdfM6y47UAJ\n\tI5/g90YawnlsooJHRrfp5NDWkDgPxEo7GKnZZ+Q8=","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=-3.4 required=5.0 tests=AWL, BAYES_00,\n\tMIME_BASE64_BLANKS, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=","X-Spam-User":"qpsmtpd, 2 recipients","X-HELO":"EUR01-DB5-obe.outbound.protection.outlook.com","From":"Alan Hayward <Alan.Hayward@arm.com>","To":"Dave P Martin <Dave.Martin@arm.com>","CC":"Dave Martin <dave.martin@foss.arm.com>, \"linux-arch@vger.kernel.org\"\n\t<linux-arch@vger.kernel.org>, \"libc-alpha@sourceware.org\"\n\t<libc-alpha@sourceware.org>,\n\t\"gdb@sourceware.org\" <gdb@sourceware.org>, \"Ard Biesheuvel\"\n\t<ard.biesheuvel@linaro.org>, Szabolcs Nagy <Szabolcs.Nagy@arm.com>,\n\tCatalin Marinas <Catalin.Marinas@arm.com>, Yao Qi <Yao.Qi@arm.com>,\n\tWill Deacon <Will.Deacon@arm.com>,\n\tRichard Sandiford <Richard.Sandiford@arm.com>, nd <nd@arm.com>,\n\t=?utf-8?q?Alex_Benn=C3=A9e?= <alex.bennee@linaro.org>,\n\t\"kvmarm@lists.cs.columbia.edu\" <kvmarm@lists.cs.columbia.edu>,\n\t\"linux-arm-kernel@lists.infradead.org\"\n\t<linux-arm-kernel@lists.infradead.org>","Subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","Date":"Thu, 21 Sep 2017 11:57:24 +0000","Message-ID":"<E7AEE685-0814-4308-97D2-4AC095A52ED2@arm.com>","References":"<1504198860-12951-1-git-send-email-Dave.Martin@arm.com>\n\t<1504198860-12951-15-git-send-email-Dave.Martin@arm.com>\n\t<FC5BA359-D37C-493C-87CD-146B83D3CCB5@arm.com>\n\t<20170920110902.GG24231@e103592.cambridge.arm.com>\n\t<E82895B2-3F95-4A54-8703-D654221F8CBA@arm.com>\n\t<20170921111937.GA17434@e103592.cambridge.arm.com>","In-Reply-To":"<20170921111937.GA17434@e103592.cambridge.arm.com>","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-84811-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=\"T8V8b4sB\"; dkim-atps=neutral","sourceware.org; auth=none","spf=none (sender IP is )\n\tsmtp.mailfrom=Alan.Hayward@arm.com; "],"x-ms-publictraffictype":"Email","x-microsoft-exchange-diagnostics":"1; DB3PR08MB0074;\n\t6:NGN8xq7adtu72IMzy6bV3mBTi9AckRJZamUzxSW1Vq0gzFN2JAfSfM0bRjnDodO4fICkpbyVOuAERCgJeH8eRXp2Tl+c+7CrGtaxlaiEOogDADNfdgtIOmqEuYrDJHBXMDs+fdDWvWhMtDlARJ7UU0C0lB096HhLU4lyasn7yQM+cvSzcNI1e9ESB6uwhdtFRfmNQoOn+sP5/n5lZjOasz+BFiH44J/Vf+f2LWDEbPy7JICLsXHdeZFMmKhyvwgGW5MEqvvIowOob4+Lmda2FjjEEFqlu69ObOCxtN34z3aHu4K7m5VPbKkcPrLLozIvsLcAjzMx7klHiBmGGhUemA==;\n\t5:7P/NTEMAze1JG/m2jfRBdVI48WFLxA89Dvcb6P+4ReDTeBhRX8/yCuSOpSNBRdmsbr9MEacnN6pSw++zHVFQbxbkRyF90EfBHih6/kf/V8uUQpEoYamtBLwTTW+4k07BHgBCy1E/DgojZQtA+vUGeQ==;\n\t24:XNIBaid82JEqIwj0kOSDalyb2Bm8FC9psJD0GhzFzXWJ7gWfqk75lCym1LCkgmXwUyJa5566ujvE0X4vWSQlMh+q+znKwcj822r4IsFBTuQ=;\n\t7:utQ0O+1FweucMaWFjDQz3jRL0+2zzqngkW3cC9OUK46o1D/GyT7P8fHVLcVS1+1R3TOlQ0nsrxPxu5Rkf+HCSgJlFumJ8cylsWF6OFgisYi1srmli85Nw+gosQ7B92J4eu+lFxG0D3untAxqS3wqBzlLp3vBjTem1PzrRCWl0WO9/3iewDLKFtv3R4tqw026PjSpvwaAH/3ySw36b3GWoL8huQuTLewIsHvVbNJ55yc=","x-ms-exchange-antispam-srfa-diagnostics":"SSOS;","x-ms-office365-filtering-correlation-id":"d333b1cb-2bbe-40e2-171f-08d500e7ec93","x-ms-office365-filtering-ht":"Tenant","x-microsoft-antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);\n\tSRVR:DB3PR08MB0074; ","x-ms-traffictypediagnostic":"DB3PR08MB0074:","nodisclaimer":"True","x-exchange-antispam-report-test":"UriScan:(180628864354917);","x-microsoft-antispam-prvs":"<DB3PR08MB007444768278657CB0ECA6A897660@DB3PR08MB0074.eurprd08.prod.outlook.com>","x-exchange-antispam-report-cfa-test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:DB3PR08MB0074; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:DB3PR08MB0074; ","x-forefront-prvs":"04371797A5","x-forefront-antispam-report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(39860400002)(376002)(346002)(189002)(199003)(24454002)(6486002)(6506006)(316002)(3660700001)(3280700002)(36756003)(93886005)(189998001)(6436002)(81166006)(81156014)(8936002)(76176999)(53546010)(8676002)(305945005)(7736002)(83716003)(54906003)(97736004)(66066001)(14454004)(5250100002)(86362001)(2906002)(37006003)(54356999)(50986999)(99286003)(102836003)(478600001)(6246003)(4326008)(72206003)(53936002)(68736007)(25786009)(33656002)(101416001)(2950100002)(6512007)(6636002)(6116002)(3846002)(82746002)(105586002)(2900100001)(6862004)(106356001)(5660300001)(229853002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR08MB0074;\n\tH:DB3PR08MB0106.eurprd08.prod.outlook.com; FPR:; SPF:None;\n\tPTR:InfoNoRecords; MX:1; A:1; LANG:en; ","received-spf":"None (protection.outlook.com: arm.com does not designate\n\tpermitted sender hosts)","spamdiagnosticoutput":"1:99","spamdiagnosticmetadata":"NSPM","Content-Type":"text/plain; charset=\"utf-8\"","Content-ID":"<C72B5FFA24A00B4E816F0BD2F22B9E01@eurprd08.prod.outlook.com>","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","X-OriginatorOrg":"arm.com","X-MS-Exchange-CrossTenant-originalarrivaltime":"21 Sep 2017 11:57:24.8207\n\t(UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"f34e5979-57d9-4aaa-ad4d-b122a662184d","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"DB3PR08MB0074"}},{"id":1780797,"web_url":"http://patchwork.ozlabs.org/comment/1780797/","msgid":"<20171005164229.GX3611@e103592.cambridge.arm.com>","list_archive_url":null,"date":"2017-10-05T16:42:29","subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","submitter":{"id":26612,"url":"http://patchwork.ozlabs.org/api/people/26612/","name":"Dave Martin","email":"Dave.Martin@arm.com"},"content":"On Wed, Sep 13, 2017 at 03:11:23PM -0700, Catalin Marinas wrote:\n> On Wed, Sep 13, 2017 at 08:06:12PM +0100, Dave P Martin wrote:\n> > On Wed, Sep 13, 2017 at 10:29:11AM -0700, Catalin Marinas wrote:\n> > > On Thu, Aug 31, 2017 at 06:00:46PM +0100, Dave P Martin wrote:\n> > > > This patch implements the core logic for changing a task's vector\n> > > > length on request from userspace.  This will be used by the ptrace\n> > > > and prctl frontends that are implemented in later patches.\n> > > > \n> > > > The SVE architecture permits, but does not require, implementations\n> > > > to support vector lengths that are not a power of two.  To handle\n> > > > this, logic is added to check a requested vector length against a\n> > > > possibly sparse bitmap of available vector lengths at runtime, so\n> > > > that the best supported value can be chosen.\n> > > > \n> > > > Signed-off-by: Dave Martin <Dave.Martin@arm.com>\n> > > > Cc: Alex Bennée <alex.bennee@linaro.org>\n> > > \n> > > Can this be merged with patch 20? It seems to add the PR_ definitions\n> > > which get actually used later when the prctl interface is added.\n> > \n> > This patch is used both by patch 19 and by patch 20, which I preferred\n> > not to merge with each other: ptrace and prctl are significantly\n> > different things.\n> > \n> > The prctl bit definitions are added here because they are the canonical\n> > definitions used by both interfaces.  The ptrace #defines are based on\n> > them.\n> > \n> > Does it make sense if I merge patch 20 into this one and apply patch 19\n> > on top?  This avoide the appearance of prctl #defines with no prctl\n> > implementation.\n> \n> That's fine, you can bring patch 20 forward. If there are other\n> non-trivial issues, feel free to ignore my comment.\n\nI've had a go at this, but I think it's going to be more trouble than\nit's worth -- there are other interdependencies between the patches\nwhich make them tricky to reorder.\n\nI could add a note in the commit message for this patch explaining why\nthe prctl flag #defines are being added here.  What do you think?\n\nCheers\n---Dave","headers":{"Return-Path":"<libc-alpha-return-85467-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-85467-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=\"J1XFL4N4\"; 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 3y7JTw1QN8z9t16\n\tfor <incoming@patchwork.ozlabs.org>;\n\tFri,  6 Oct 2017 03:42:44 +1100 (AEDT)","(qmail 40978 invoked by alias); 5 Oct 2017 16:42:37 -0000","(qmail 40379 invoked by uid 89); 5 Oct 2017 16:42:36 -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=TvLR0sbQxunll5EXDbeSF7IPE1bdHc\n\tLR5F8dXLscEEHBrUV47yY+DhKhVRhsn8b3aQOWRBmiwA6epJodJp1igtIj4JZOMu\n\tIKgfRIJ1DTy9v0vKpVItCfhKj8JSoQHERBmyon+AQcni5O72u0B90MwfmMtORylA\n\tEdAaPXxBa/8cw=","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=ZmCyQ3RXAjA6L2gY0SN1Px9wPAA=; b=J1XF\n\tL4N49otpJIqThr4NxZeFOjRkh4UUGDajTUG4cdbJlG9HgB26/FTRWt88UhiZTnXK\n\t6VIUTEEYNUQJd9V6TK5pRQqBGTCCxzhITEdvWy6pWriTq7bhp6ph0Idbgfvtwa2o\n\t+kb5bmtIdAiIYOAEOcQd+JFQsxhsdkZemeGvhUY=","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,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=appearance, Alex","X-Spam-User":"qpsmtpd, 2 recipients","X-HELO":"foss.arm.com","Date":"Thu, 5 Oct 2017 17:42:29 +0100","From":"Dave Martin <Dave.Martin@arm.com>","To":"Catalin Marinas <catalin.marinas@arm.com>","Cc":"linux-arch@vger.kernel.org, libc-alpha@sourceware.org, Ard Biesheuvel\n\t<ard.biesheuvel@linaro.org>, Szabolcs Nagy <szabolcs.nagy@arm.com>,\n\tgdb@sourceware.org, Yao Qi <Yao.Qi@arm.com>,\n\tAlan Hayward <alan.hayward@arm.com>, Will Deacon <will.deacon@arm.com>, \n\tRichard Sandiford <richard.sandiford@arm.com>, Alex\n\t=?iso-8859-1?q?Benn=E9e?= <alex.bennee@linaro.org>,\n\tkvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org","Subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","Message-ID":"<20171005164229.GX3611@e103592.cambridge.arm.com>","References":"<1504198860-12951-1-git-send-email-Dave.Martin@arm.com>\n\t<1504198860-12951-15-git-send-email-Dave.Martin@arm.com>\n\t<20170913172911.3ca2h6cpju7etifi@localhost>\n\t<20170913190611.GC23415@e103592.cambridge.arm.com>\n\t<20170913221123.y4znytmxtplx24m4@localhost>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20170913221123.y4znytmxtplx24m4@localhost>","User-Agent":"Mutt/1.5.23 (2014-03-12)"}},{"id":1780818,"web_url":"http://patchwork.ozlabs.org/comment/1780818/","msgid":"<20171005165334.cstx6fszl7shaudg@armageddon.cambridge.arm.com>","list_archive_url":null,"date":"2017-10-05T16:53:34","subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","submitter":{"id":938,"url":"http://patchwork.ozlabs.org/api/people/938/","name":"Catalin Marinas","email":"catalin.marinas@arm.com"},"content":"On Thu, Oct 05, 2017 at 05:42:29PM +0100, Dave P Martin wrote:\n> On Wed, Sep 13, 2017 at 03:11:23PM -0700, Catalin Marinas wrote:\n> > On Wed, Sep 13, 2017 at 08:06:12PM +0100, Dave P Martin wrote:\n> > > On Wed, Sep 13, 2017 at 10:29:11AM -0700, Catalin Marinas wrote:\n> > > > On Thu, Aug 31, 2017 at 06:00:46PM +0100, Dave P Martin wrote:\n> > > > > This patch implements the core logic for changing a task's vector\n> > > > > length on request from userspace.  This will be used by the ptrace\n> > > > > and prctl frontends that are implemented in later patches.\n> > > > > \n> > > > > The SVE architecture permits, but does not require, implementations\n> > > > > to support vector lengths that are not a power of two.  To handle\n> > > > > this, logic is added to check a requested vector length against a\n> > > > > possibly sparse bitmap of available vector lengths at runtime, so\n> > > > > that the best supported value can be chosen.\n> > > > > \n> > > > > Signed-off-by: Dave Martin <Dave.Martin@arm.com>\n> > > > > Cc: Alex Bennée <alex.bennee@linaro.org>\n> > > > \n> > > > Can this be merged with patch 20? It seems to add the PR_ definitions\n> > > > which get actually used later when the prctl interface is added.\n> > > \n> > > This patch is used both by patch 19 and by patch 20, which I preferred\n> > > not to merge with each other: ptrace and prctl are significantly\n> > > different things.\n> > > \n> > > The prctl bit definitions are added here because they are the canonical\n> > > definitions used by both interfaces.  The ptrace #defines are based on\n> > > them.\n> > > \n> > > Does it make sense if I merge patch 20 into this one and apply patch 19\n> > > on top?  This avoide the appearance of prctl #defines with no prctl\n> > > implementation.\n> > \n> > That's fine, you can bring patch 20 forward. If there are other\n> > non-trivial issues, feel free to ignore my comment.\n> \n> I've had a go at this, but I think it's going to be more trouble than\n> it's worth -- there are other interdependencies between the patches\n> which make them tricky to reorder.\n> \n> I could add a note in the commit message for this patch explaining why\n> the prctl flag #defines are being added here.  What do you think?\n\nAs I said, it's up to you. A line in the commit message would do.","headers":{"Return-Path":"<libc-alpha-return-85471-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-85471-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=\"Yu9f11pD\"; 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 3y7Jkh5FFLz9t2l\n\tfor <incoming@patchwork.ozlabs.org>;\n\tFri,  6 Oct 2017 03:53:48 +1100 (AEDT)","(qmail 27689 invoked by alias); 5 Oct 2017 16:53:42 -0000","(qmail 27664 invoked by uid 89); 5 Oct 2017 16:53:42 -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=RyrK8spco4RfMwTLxnj8d//axAI6UN\n\tHIR0xj076GFB0Iqjvw9rOu7btvjfDEhXdYI9wMofypsoEOnKuo87+7FYatQdJFbO\n\tmn8MsyUppMSAbRTndkyKhBU0kPv5jE6JoN+I+r3UnwmelFrObgeSpy21KW/Z+Xbm\n\tzycgMpVe8YSAs=","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=JW3gMGGLShusWgibiXGz6WsdqKE=; b=Yu9f\n\t11pDms4UYR6rl4hpCiHs2tYUc8MUtMnR4K6qkAZpfk1plL9jcvLV+nY61Q0yxZI3\n\tBz3PgLH9fTRuCFtfT3ZI9G8epyOwJEyy+bBb3iMBy5svyljGs8Ilc+vOG1I8ZBqb\n\tvtg/C8VHLKbmqvJ3ueiSg7Z/mbtlH6e/4Ll03LY=","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-Spam-User":"qpsmtpd, 2 recipients","X-HELO":"foss.arm.com","Date":"Thu, 5 Oct 2017 17:53:34 +0100","From":"Catalin Marinas <catalin.marinas@arm.com>","To":"Dave Martin <Dave.Martin@arm.com>","Cc":"linux-arch@vger.kernel.org, libc-alpha@sourceware.org, Ard Biesheuvel\n\t<ard.biesheuvel@linaro.org>, Szabolcs Nagy <szabolcs.nagy@arm.com>,\n\tgdb@sourceware.org, Yao Qi <Yao.Qi@arm.com>,\n\tWill Deacon <will.deacon@arm.com>, Richard Sandiford\n\t<richard.sandiford@arm.com>, \tAlan Hayward <alan.hayward@arm.com>, Alex\n\t=?iso-8859-1?q?Benn=E9e?= <alex.bennee@linaro.org>,\n\tkvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org","Subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","Message-ID":"<20171005165334.cstx6fszl7shaudg@armageddon.cambridge.arm.com>","References":"<1504198860-12951-1-git-send-email-Dave.Martin@arm.com>\n\t<1504198860-12951-15-git-send-email-Dave.Martin@arm.com>\n\t<20170913172911.3ca2h6cpju7etifi@localhost>\n\t<20170913190611.GC23415@e103592.cambridge.arm.com>\n\t<20170913221123.y4znytmxtplx24m4@localhost>\n\t<20171005164229.GX3611@e103592.cambridge.arm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20171005164229.GX3611@e103592.cambridge.arm.com>","User-Agent":"NeoMutt/20170113 (1.7.2)"}},{"id":1780829,"web_url":"http://patchwork.ozlabs.org/comment/1780829/","msgid":"<20171005170446.GZ3611@e103592.cambridge.arm.com>","list_archive_url":null,"date":"2017-10-05T17:04:47","subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","submitter":{"id":26612,"url":"http://patchwork.ozlabs.org/api/people/26612/","name":"Dave Martin","email":"Dave.Martin@arm.com"},"content":"On Thu, Oct 05, 2017 at 05:53:34PM +0100, Catalin Marinas wrote:\n> On Thu, Oct 05, 2017 at 05:42:29PM +0100, Dave P Martin wrote:\n> > On Wed, Sep 13, 2017 at 03:11:23PM -0700, Catalin Marinas wrote:\n> > > On Wed, Sep 13, 2017 at 08:06:12PM +0100, Dave P Martin wrote:\n> > > > On Wed, Sep 13, 2017 at 10:29:11AM -0700, Catalin Marinas wrote:\n\n[...]\n\n> > > > > Can this be merged with patch 20? It seems to add the PR_ definitions\n> > > > > which get actually used later when the prctl interface is added.\n> > > > \n> > > > This patch is used both by patch 19 and by patch 20, which I preferred\n> > > > not to merge with each other: ptrace and prctl are significantly\n> > > > different things.\n> > > > \n> > > > The prctl bit definitions are added here because they are the canonical\n> > > > definitions used by both interfaces.  The ptrace #defines are based on\n> > > > them.\n> > > > \n> > > > Does it make sense if I merge patch 20 into this one and apply patch 19\n> > > > on top?  This avoide the appearance of prctl #defines with no prctl\n> > > > implementation.\n> > > \n> > > That's fine, you can bring patch 20 forward. If there are other\n> > > non-trivial issues, feel free to ignore my comment.\n> > \n> > I've had a go at this, but I think it's going to be more trouble than\n> > it's worth -- there are other interdependencies between the patches\n> > which make them tricky to reorder.\n> > \n> > I could add a note in the commit message for this patch explaining why\n> > the prctl flag #defines are being added here.  What do you think?\n> \n> As I said, it's up to you. A line in the commit message would do.\n\nOK, I think I'll stick with this then.\n\nCheers\n---Dave","headers":{"Return-Path":"<libc-alpha-return-85477-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-85477-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=\"wmc8fyj0\"; 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 3y7K0456DDz9t2l\n\tfor <incoming@patchwork.ozlabs.org>;\n\tFri,  6 Oct 2017 04:05:24 +1100 (AEDT)","(qmail 44253 invoked by alias); 5 Oct 2017 17:04:54 -0000","(qmail 44235 invoked by uid 89); 5 Oct 2017 17:04:54 -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:in-reply-to; q=dns; s=default; b=jEzg\n\tOqSmJeuYurkMOvbMHOuBP58qdnGQvOlPvkitdWNuqpiUK61GV5XBC0oqHvoJ/4rB\n\tFK1iTcg4Uw0lf0R41T3NziE5uXq4Waep+EkgobtBYt9j/HCmFjYweTS7lJiYOJsT\n\tKyb9jORyFzzF3aedKGMdiRONFk3pJCgzkl//2mQ=","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:in-reply-to; s=default; bh=bla39j524D\n\t8A8yJzZZO1CBsEXIA=; b=wmc8fyj09dRbuzdHRZ3+TYhjvqPxCPfGyqlQ2uzX98\n\tsfJQaqAVvn/FYKotgDSXSAYyeDXC3V6Or0GeAMMcw4KN4RkUe6VgJu+r6z3fG/H2\n\t5+lWoaOB8+7fs9sbZurYXuZWqkh5w/RV4G0+KSLXusUkSjqMfTJnOICV24LbFE3Z\n\tk=","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,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1731","X-Spam-User":"qpsmtpd, 2 recipients","X-HELO":"foss.arm.com","Date":"Thu, 5 Oct 2017 18:04:47 +0100","From":"Dave Martin <Dave.Martin@arm.com>","To":"Catalin Marinas <catalin.marinas@arm.com>","Cc":"linux-arch@vger.kernel.org, libc-alpha@sourceware.org, Ard Biesheuvel\n\t<ard.biesheuvel@linaro.org>, Szabolcs Nagy <szabolcs.nagy@arm.com>,\n\tgdb@sourceware.org, Yao Qi <Yao.Qi@arm.com>,\n\tAlan Hayward <alan.hayward@arm.com>, Will Deacon <will.deacon@arm.com>, \n\tRichard Sandiford <richard.sandiford@arm.com>, Alex\n\t=?iso-8859-1?q?Benn=E9e?= <alex.bennee@linaro.org>,\n\tkvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org","Subject":"Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector\n\tlength","Message-ID":"<20171005170446.GZ3611@e103592.cambridge.arm.com>","References":"<1504198860-12951-1-git-send-email-Dave.Martin@arm.com>\n\t<1504198860-12951-15-git-send-email-Dave.Martin@arm.com>\n\t<20170913172911.3ca2h6cpju7etifi@localhost>\n\t<20170913190611.GC23415@e103592.cambridge.arm.com>\n\t<20170913221123.y4znytmxtplx24m4@localhost>\n\t<20171005164229.GX3611@e103592.cambridge.arm.com>\n\t<20171005165334.cstx6fszl7shaudg@armageddon.cambridge.arm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20171005165334.cstx6fszl7shaudg@armageddon.cambridge.arm.com>","User-Agent":"Mutt/1.5.23 (2014-03-12)"}}]