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,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,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 4312BC433E3 for ; Tue, 14 Jul 2020 15:18:49 +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 1536122404 for ; Tue, 14 Jul 2020 15:18:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="0NYNo4Q9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1536122404 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.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:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=oqc5MU+20GX75RYsemnpnzH+OkSzOqO7Q1FHFa+tEoY=; b=0NYNo4Q92FKkUib2AVfmLLCzy a3ZED5Ou9Z/cVoSelyotCiMsyQgBc0TyRxuytl+gn0RtmckfCwWghOxHvNxZaTWJIyJJK8hJA+EGN UoEdD7NxE2PfaUkWOy24LaeVShtbD8RLFZKpnp0dUTZcwToxEw3ePmrV+fYTZozwmcMrZRkIZkZdI 2qmcH9RlvmCgpjGOzY18lijFjqhxK/SRo/6fJv3McbRZnt+mi3H1PfipbkxdiuJQ3Z11wlBf/tb1S 584tZL44k6umo2J78ICQWQdOlUjd9WKSj+6ExC5VVNNMztOdIQg/LMLL4EvQWF65sjGn57KlPQ3rh nRL4FN7lg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jvMgI-00014X-Qf; Tue, 14 Jul 2020 15:17:18 +0000 Received: from szxga06-in.huawei.com ([45.249.212.32] helo=huawei.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jvMgF-00013k-U0 for linux-arm-kernel@lists.infradead.org; Tue, 14 Jul 2020 15:17:17 +0000 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id A7B0A3B5B896DCDB36BD; Tue, 14 Jul 2020 23:17:09 +0800 (CST) Received: from [127.0.0.1] (10.174.186.75) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.487.0; Tue, 14 Jul 2020 23:17:03 +0800 Subject: Re: [PATCH v2 0/2] arm64: tlb: add support for TLBI RANGE instructions To: Catalin Marinas 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> From: Zhenyu Ye Message-ID: Date: Tue, 14 Jul 2020 23:17:01 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <20200713165903.GD15829@gaia> X-Originating-IP: [10.174.186.75] X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200714_111716_756156_A04F9EB8 X-CRM114-Status: GOOD ( 21.43 ) 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: linux-arch@vger.kernel.org, suzuki.poulose@arm.com, maz@kernel.org, linux-kernel@vger.kernel.org, xiexiangyou@huawei.com, steven.price@arm.com, zhangshaokun@hisilicon.com, linux-mm@kvack.org, arm@kernel.org, prime.zeng@hisilicon.com, guohanjun@huawei.com, olof@lixom.net, kuhn.chenqun@huawei.com, will@kernel.org, linux-arm-kernel@lists.infradead.org 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 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) >> + >> endmenu > > 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'm slightly surprised that my toolchains (and yours) did not complain > about these instructions. Looking at the binutils code, I think it > should have complained if -march=armv8.4-a wasn't passed but works fine. > I thought gas doesn't enable the maximum arch feature by default. >> An alternative would be to check for a specific instruction (untested): > > def_bool $(as-instr,tlbi rvae1is, x0) > > but we need to figure out whether gas not requiring -march=armv8.4-a is > a bug (which may be fixed) or that gas accepts all TLBI instructions. > As you say in another email, this is a bug. So we should pass -march= armv8.4-a to gas if we use toolchains to generate tlbi range instructions. But this bug only affects the compilation (cause WARNING or ERROR if not pass -march-armv8.4-a when compiling) but not the judgment. > 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. Thanks, Zhenyu _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel