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.5 required=3.0 tests=BAYES_00, 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 1F640C433E0 for ; Tue, 14 Jul 2020 15:58:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C7E5C22461 for ; Tue, 14 Jul 2020 15:58:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C7E5C22461 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5877C6B0008; Tue, 14 Jul 2020 11:58:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 537D16B0023; Tue, 14 Jul 2020 11:58:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 426506B0024; Tue, 14 Jul 2020 11:58:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0083.hostedemail.com [216.40.44.83]) by kanga.kvack.org (Postfix) with ESMTP id 29CAD6B0008 for ; Tue, 14 Jul 2020 11:58:49 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id CDB23824999B for ; Tue, 14 Jul 2020 15:58:48 +0000 (UTC) X-FDA: 77037139536.19.cup76_1e1209626ef2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id 92DA71ACC22 for ; Tue, 14 Jul 2020 15:58:47 +0000 (UTC) X-HE-Tag: cup76_1e1209626ef2 X-Filterd-Recvd-Size: 4259 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Tue, 14 Jul 2020 15:58:46 +0000 (UTC) Received: from gaia (unknown [95.146.230.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 93708223C6; Tue, 14 Jul 2020 15:58:43 +0000 (UTC) Date: Tue, 14 Jul 2020 16:58:41 +0100 From: Catalin Marinas To: Zhenyu Ye Cc: maz@kernel.org, steven.price@arm.com, guohanjun@huawei.com, will@kernel.org, olof@lixom.net, suzuki.poulose@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, zhangshaokun@hisilicon.com, prime.zeng@hisilicon.com, linux-arch@vger.kernel.org, kuhn.chenqun@huawei.com, xiexiangyou@huawei.com, linux-mm@kvack.org, arm@kernel.org Subject: Re: [PATCH v2 0/2] arm64: tlb: add support for TLBI RANGE instructions Message-ID: <20200714155840.GE18793@gaia> References: <20200710094420.517-1-yezhenyu2@huawei.com> <159440712962.27784.4664678472466095995.b4-ty@arm.com> <20200713122123.GC15829@gaia> <2edcf1ce-38d4-82b2-e500-51f742cae357@huawei.com> <20200713165903.GD15829@gaia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 92DA71ACC22 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jul 14, 2020 at 11:17:01PM +0800, Zhenyu Ye wrote: > On 2020/7/14 0:59, Catalin Marinas wrote: > >> +config ARM64_TLBI_RANGE > >> + bool "Enable support for tlbi range feature" > >> + default y > >> + depends on AS_HAS_TLBI_RANGE > >> + help > >> + ARMv8.4-TLBI provides TLBI invalidation instruction that apply to a > >> + range of input addresses. > >> + > >> + The feature introduces new assembly instructions, and they were > >> + support when binutils >= 2.30. > > > > It looks like 2.30. I tracked it down to this commit: > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=793a194839bc8add71fdc7429c58b10f0667a6f6;hp=1a7ed57c840dcb0401f1a67c6763a89f7d2686d2 > > > >> +config AS_HAS_TLBI_RANGE > >> + def_bool $(as-option, -Wa$(comma)-march=armv8.4-a) You could make this more generic like AS_HAS_ARMV8_4. > > The problem is that we don't pass -Wa,-march=armv8.4-a to gas. AFAICT, > > we only set an 8.3 for PAC but I'm not sure how passing two such options > > goes. > > Pass the -march twice may not have bad impact. Test in my toolchains > and the newer one will be chosen. Anyway, we can add judgment to avoid > them be passed at the same time. I think the last one always overrides the previous (same with the .arch statements in asm files). For example: echo "paciasp" | aarch64-none-linux-gnu-as -march=armv8.2-a -march=armv8.3-a succeeds but the one below fails: echo "paciasp" | aarch64-none-linux-gnu-as -march=armv8.3-a -march=armv8.2-a > > A safer bet may be to simply encode the instructions by hand: > > > > #define SYS_TLBI_RVAE1IS(Rt) \ > > __emit_inst(0xd5000000 | sys_insn(1, 0, 8, 2, 1) | ((Rt) & 0x1f)) > > #define SYS_TLBI_RVALE1IS(Rt) \ > > __emit_inst(0xd5000000 | sys_insn(1, 0, 8, 2, 5) | ((Rt) & 0x1f)) > > > > (please check that they are correct) > > Currently in kernel, all tlbi instructions are passed through __tlbi() > and __tlbi_user(). If we encode the range instructions by hand, we may > should have to add a new mechanism for this: > > 1. choose a register and save it; > 2. put the operations for tlbi range to the register; > 3. do tlbi range by asm(SYS_TLBI_RVAE1IS(x0)); > 4. restore the value of the register. > > It's complicated and will only be used with tlbi range instructions. > (Am I understand something wrong? ) > > So I am prefer to pass -march=armv8.4-a to toolschains to support tlbi > range instruction, just like what PAC does. It will indeed get more complicated than necessary. So please go with the -Wa,-march=armv8.4-a check in Kconfig and update the arch/arm64/Makefile to pass this option (after the 8.3 one). Thanks. -- Catalin