Received: by 10.223.185.116 with SMTP id b49csp1021621wrg; Wed, 21 Feb 2018 10:42:35 -0800 (PST) X-Google-Smtp-Source: AH8x22457syX+TM94XUfBRa0u2bgT76DyVM3dD89EaKUTlcK9H6UvZ5fpnlkHWD775iTR5oLDX+V X-Received: by 10.98.7.73 with SMTP id b70mr4158534pfd.39.1519238555695; Wed, 21 Feb 2018 10:42:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519238555; cv=none; d=google.com; s=arc-20160816; b=GNK3vOMNM5Tl23omcmTJWwai8F36Fre1eua/Ats3Q4lzFBoTPd84XKbD1gkK8zaliY np7AY0zRd+VztUZHjM9Yxs7iv0/I/+CwwC+govVLZKKurQLyzz++t5cBXMBPiXy50745 1cV7J//xAPKj2g2l2Lp9OQUz0XAWa2UQJxZ/OnznevNcvtRstUUDtwweKFdjYoYc0uyg B851hAil+hnW60VavYM7eOAHiUCsjcoEGF4JIzJgqEwOyCbA8vyjObpJpqiW3r4dk2ew Xgnx3m2U1uQPg3373zyvSwxqvWK0Y6//Bdbm4QVlRoYAG5FEoGfx5cbDAEVgD5S3rpNr 2rKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=UmluHE+O0bD9MUVF9qSU0QyZpWtbF4eJknWelaEKoHs=; b=BrrGNsOBDZ4TmXhcOPcTmuAVwywc9GjXUBZn2+AeJswm5WpbcEkBzL9YseSInPnets pIrTpg8gv6UX7BWUeoRPrA7y6enUQPdnMYRAj9MZWuUn2y87PiEn+rI9M1IKXtD5HwFu BIQHZyR9grzxUY7qWlGSCjDgmCzLGfHwck8canKHT5DPUEJW365qdzHPFM0wefQoimOi /bZYMtbo89mo1XGF/3MrBLvsEkRG29v/bTOQryl3pYyW2Qxapz/lrRIbwpQ4Ugb0tknX XHKryw5kc/p2OFtbHCHlWDCeOws+uJG00g2YDUi6ZaOsqdNVTR1YMEXIg3/xfigr4EIg kOkw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c3-v6si1470406plo.708.2018.02.21.10.42.21; Wed, 21 Feb 2018 10:42:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936586AbeBUNVl (ORCPT + 99 others); Wed, 21 Feb 2018 08:21:41 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:54426 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752736AbeBUNMF (ORCPT ); Wed, 21 Feb 2018 08:12:05 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8B6241435; Wed, 21 Feb 2018 05:12:04 -0800 (PST) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 5C2253F318; Wed, 21 Feb 2018 05:12:04 -0800 (PST) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id 3E1361AE51CB; Wed, 21 Feb 2018 13:12:04 +0000 (GMT) Date: Wed, 21 Feb 2018 13:12:04 +0000 From: Will Deacon To: Shanker Donthineni Cc: Catalin Marinas , Thomas Speier , Vikram Sethi , Marc Zyngier , linux-kernel , Philip Elcan , kvmarm , linux-arm-kernel Subject: Re: [PATCH v2] arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC Message-ID: <20180221131203.GB7614@arm.com> References: <1519095546-24420-1-git-send-email-shankerd@codeaurora.org> <20180221111233.gylb6v4yxqnn6gyj@localhost> <23d70753-a628-f2e4-84df-39e4021337f5@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23d70753-a628-f2e4-84df-39e4021337f5@codeaurora.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 21, 2018 at 07:10:34AM -0600, Shanker Donthineni wrote: > On 02/21/2018 05:12 AM, Catalin Marinas wrote: > > However, my worry is that in an implementation with DIC set, we also > > skip the DSB/ISB sequence in the invalidate_icache_by_line macro. For > > example, in an implementation with transparent PoU, we could have: > > > > str , [addr] > > // no cache maintenance or barrier > > br > > > > Thanks for pointing out the missing barriers. I think it make sense to follow > the existing barrier semantics in order to avoid the unknown things. > > > Is an ISB required between the instruction store and execution? I would > > say yes but maybe Will has a better opinion here. > > > Agree, an ISB is required especially for self-modifying code. I'll include in v3 patch. I'd have thought you'd need a DSB too, before the ISB. Will