From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 429A5C433DB for ; Wed, 10 Feb 2021 18:17:05 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DC9D364E15 for ; Wed, 10 Feb 2021 18:17:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DC9D364E15 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=+JeblGHFokW+TcDz5udvIlIrN73qhkWDrtGxOKLBl40=; b=HlFz1L5lg//iOiXAY3kpwnETW ugD93kRD98JONXsQLGzi0PJDf8TCBCLGGF1JwNNaRmJWiy2siYK3s2Ca16a2e9TS6iuPcs9KB2mCg GJoMIC/DLmn5J5wCCRVzKmh7ioAXFW4nFY8ARUOMhhO3zEjzHHtFS5I83s/YYcyC6AS+1MIFiYHs0 PebwAxmdQuQGQDraAoP5jY5LXcG5PiJqdBlfc2vT8+nNnsOXXAN8E+qO0ctZIMfWzvmLJZV5bhDeI eKi5s4KwuvdoWZUjv87ttuLaZjRC/M7lBHUhE3clRl7qs2quRt9diWW7TareNBmLjQ5ut54hjKlVS fbv2q9U2g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9u1w-0003nV-72; Wed, 10 Feb 2021 18:16:00 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9u1t-0003mg-C4 for linux-arm-kernel@lists.infradead.org; Wed, 10 Feb 2021 18:15:58 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 94D67ED1; Wed, 10 Feb 2021 10:15:53 -0800 (PST) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 73F453F73D; Wed, 10 Feb 2021 10:15:52 -0800 (PST) Date: Wed, 10 Feb 2021 18:15:30 +0000 From: Dave Martin To: Mark Brown Subject: Re: [PATCH v7 1/2] arm64/sve: Split TIF_SVE into separate execute and register state flags Message-ID: <20210210181530.GL21837@arm.com> References: <20210201122901.11331-1-broonie@kernel.org> <20210201122901.11331-2-broonie@kernel.org> <20210210105650.GI21837@arm.com> <20210210145452.GA4748@sirena.org.uk> <20210210154249.GK21837@arm.com> <20210210171442.GC4748@sirena.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210210171442.GC4748@sirena.org.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210210_131557_544486_A6ABE48A X-CRM114-Status: GOOD ( 31.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Julien Grall , Catalin Marinas , Zhang Lei , Will Deacon , linux-arm-kernel@lists.infradead.org, Daniel Kiss Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Feb 10, 2021 at 05:14:42PM +0000, Mark Brown wrote: > On Wed, Feb 10, 2021 at 03:42:51PM +0000, Dave Martin wrote: > > On Wed, Feb 10, 2021 at 02:54:52PM +0000, Mark Brown wrote: > > > > Oh, *that's* what that's all about. I spent quite a bit of time trying > > > to figure out why we were sometimes using vq_minus_1 but never managed > > > to get to the bottom of it - it's an awkward name and there's nothing in > > > the code that explains the logic behind when we use it so it was really > > > confusing. We can do the rename but I'm not sure it's achieving the > > > goal of comprehensibility. > > > Ah, I see. The reason for the difference is that the vector length is > > encoded in ZCR_ELx.LEN as the vector length in quadwords ("vq" -- see > > Documentation/arm64/sve.rst) minus one. It seemed poor practice to do > > the conversion in asm where the compiler can't see or optimise it, plus > > I didn't want the possibility of passing meaningless values at that > > level. So the caller has to validate the vector length with > > sve_vl_valid() where deemed necessary, and then convert explicitly. > > Yeah, it's relatively clear to get to the fact that it's due to the > ZCR_ELx.LEN - what was not at all clear was what the rule for choosing > between the two representations was, my instinct would've been to hide > the different representation, something like a static inline wrapper for > the assembly function would still let the compiler see what's going on. We could certainly do that. One reason why I didn't go for that initially is that the ZCR setting is done in low-level places where we don't really want to have to BUG(). Requiring the caller to do something explicit reduces the change of someone passing in an unchecked garbage value for the vl. But provided the caller checks with sve_vl_valid(), or we are confident by construction that the value is valid, this doesn't really matter. Due to a lot of painful debugging, I became pretty paranoid when upstreaming the initial code. We should keep some of that paranoia, but we probably don't need quite so much of it now. > > Either way, calling this "vl" is breaking a useful convention that's > > followed throughout the rest of the kernel, so I'd prefer we call it > > something else -- but within reason, I don't mind what name is used. > > That's the convention in the arm64 FP code or something else? It's the convention I made up for the arm64 SVE code and user/kernel API -- so when I say "the rest of the kernel", I just mean arch/arm64/. The rest of the kernel doesn't contain any SVE code that doesn't follow this convention, so I can claim it is followed everywhere ;) In the architecture, "VL" is a looser concept that in most contexts means something like "the size of a vector", but it can be a bit unexpected -- as in the ", MUL VL" addressing mode syntax for example. Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel