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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 6B34FC432C0 for ; Tue, 19 Nov 2019 10:03:46 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 3DFC820878 for ; Tue, 19 Nov 2019 10:03:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="QlcmUqBJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3DFC820878 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:From:Date: MIME-Version:Subject:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=MD/E2tP928lRBS5Fqx48q9axa3Jn+Dz03ys01G7WanQ=; b=QlcmUqBJ+JrpyDP+GVcSJkNrt 3sbCQf9iSxR1tWd6cU8S4VmMp8y74PC8UABZ2Rjbf1P9DdXm6OM9Bsxkch1779lTxQC7UPgnG3P0h l6krJmhdR5iYIdnN9lPYwCgiIq17lNCget9YhXON7sRlLT9IkIqr7ujSSwBMXqdauATV5NvWMykSs Kw3I1K+pnTVj7z6syD/lNz/uupvVSjNGNAJdgHkFi87GMN82Pd5SsjHBYr1bsMNmCstUKeezfLflS 5HR+hiNWISbd/L6GLZ1ZRIMeoAxNgu+Kyj1UwlPfYzWjry7qYBGCk7ytuCX9sBE2dxE0QU17+7+7l E3LFWSkew==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iX0MI-0005et-FE; Tue, 19 Nov 2019 10:03:42 +0000 Received: from inca-roads.misterjones.org ([213.251.177.50]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iX0ME-0005e4-6Q for linux-arm-kernel@lists.infradead.org; Tue, 19 Nov 2019 10:03:39 +0000 Received: from www-data by cheepnis.misterjones.org with local (Exim 4.80) (envelope-from ) id 1iX0MA-0001a9-8z; Tue, 19 Nov 2019 11:03:34 +0100 To: Hanjun Guo Subject: Re: [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range instructions X-PHP-Originating-Script: 0:main.inc MIME-Version: 1.0 Date: Tue, 19 Nov 2019 10:03:34 +0000 From: Marc Zyngier In-Reply-To: References: <5DC960EB.9050503@huawei.com> <20191111132716.GA9394@willie-the-truck> <5DC96660.8040505@huawei.com> Message-ID: X-Sender: maz@kernel.org User-Agent: Roundcube Webmail/0.7.2 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: guohanjun@huawei.com, yezhenyu2@huawei.com, will@kernel.org, catalin.marinas@arm.com, suzuki.poulose@arm.com, mark.rutland@arm.com, tangnianyao@huawei.com, xiexiangyou@huawei.com, linux-kernel@vger.kernel.org, arm@kernel.org, linux-arm-kernel@lists.infradead.org, linuxarm@huawei.com, zhangshaokun@hisilicon.com, wanghuiqiang@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on cheepnis.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191119_020338_383482_52AE758F X-CRM114-Status: GOOD ( 16.40 ) 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: mark.rutland@arm.com, wanghuiqiang , suzuki.poulose@arm.com, catalin.marinas@arm.com, Zhenyu Ye , linux-kernel@vger.kernel.org, xiexiangyou@huawei.com, Linuxarm , Shaokun Zhang , arm@kernel.org, tangnianyao@huawei.com, Will Deacon , linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Hanjun, On 2019-11-19 01:13, Hanjun Guo wrote: > +Cc linux-arm-kernel mailing list and Shaokun. > > Hi Marc, > > On 2019/11/11 22:04, Marc Zyngier wrote: >> On 2019-11-11 14:56, Zhenyu Ye wrote: >>> On 2019/11/11 21:27, Will Deacon wrote: >>>> On Mon, Nov 11, 2019 at 09:23:55PM +0800, Zhenyu Ye wrote: > [...] >>>> >>>> How does this address my concerns here: >>>> >>>> >>>> >>>> https://lore.kernel.org/linux-arm-kernel/20191031131649.GB27196@willie-the-truck/ >>>> >>>> ? >>>> >>>> Will >>> >>> I think your concern is more about the hardware level, and we can >>> do >>> nothing about >>> this at all. The interconnect/DVM implementation is not exposed to >>> software layer >>> (and no need), and may should be constrained at hardware level. >> >> You're missing the point here: the instruction may be implemented >> and perfectly working at the CPU level, and yet not carried over >> the interconnect. In this situation, other CPUs may not observe >> the DVM messages instructing them of such invalidation, and you'll >> end >> up with memory corruption. >> >> So, in the absence of an architectural guarantee that range >> invalidation >> is supported and observed by all the DVM agents in the system, there >> must >> be a firmware description for it on which the kernel can rely. > > I'm thinking of how to add a firmware description for it, how about > this: > > Adding a system level flag to indicate the supporting of TIBi by > range, > which means adding a binding name for example "tlbi-by-range" at > system > level in the dts file, or a tlbi by range flag in ACPI FADT table, > then > we use the ID register per-cpu and the system level flag as > > if (cpus_have_const_cap(ARM64_HAS_TLBI_BY_RANGE) && > system_level_tlbi_by_range) > flush_tlb_by_range() > else > flush_tlb_range() > > And this seems work for heterogeneous system (olny parts of the CPU > support > TLBi by range) as well, correct me if anything wrong. It could work, but it needs to come with the strongest guarantees that all the DVM agents in the system understand this type of invalidation, specially as we move into the SVM territory. It may also need to cope with non-compliant agents being hot-plugged, or at least discovered late. I also wonder if the ARMv8.4-TTL extension (which I have patches for in the nested virt series) requires the same kind of treatment (after all, it has an implicit range based on the base granule size and level). In any way, this requires careful specification, and I don't think we can improvise this on the ML... ;-) Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel