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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id C837BEB64D7 for ; Mon, 26 Jun 2023 12:16:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=eOGLtC4zcB4ApF2vGHMH4Cw62T5GkGSUSDNweisSGF0=; b=V2KaGvbQ64oTak BXmXzYJiJtbyyeHEA+xrVfK2ATAm3Ni47eEpxOndcLlMVYpLVQuJVwBH75xGM0K7NChviQArh7tmh ZwXLaCnr/UF60XW+iakclbTxylKIc0ypzpI0KqeHM0Wa4KPMdQhFXpDxnkTmr5U8gOr2VYxFtM4sw UZG1Nt9c8LVI3LxcL1NXkkg64Ek0EciGq15JHkNwIsjDPq8ozUILeSQ7/VWiXrhbB85KzF+8cTwSf X+U9PQEd277YVcL2OglMbypTvenI1safXZFs0u4RDgl9Kuu+j2HaVLnpBGGotVVrVCm8KyzwXCqvs /mpLnw8dbbcJYQEeNM4A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qDl87-00AB7l-1D; Mon, 26 Jun 2023 12:15:39 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qDl84-00AB74-3B for linux-arm-kernel@lists.infradead.org; Mon, 26 Jun 2023 12:15:38 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BF01260DFB; Mon, 26 Jun 2023 12:15:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21F0DC433C8; Mon, 26 Jun 2023 12:15:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687781735; bh=nn+jaw4bmUIIokTJRvSbXnkzMEfUrUs92O6v4VLUcWI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=E4HB3BQkLBMJRF5m9ZULRSWZYXU2qrlqnS7fRUypOmGz5o4NvV4+ImZtx3MZFZ8g+ 2vABfBtUzpU9SgI6updQV1fNDBLExomMzSzxFkBtf2M8/tLQkN7TEfpFeZWl2MZobM 5EhnT0CbihSVBjVWIwKcfgTTJnpJeLK1RdHsqO8kJuzZ3j9N6ZVQ5Y39A7sm2/19ZL TAFZcO0ICHF8nscjdYrKsergCd0BjGOqPNbV5nltbS1S02ZQEc1lW/FlwqzAdKWp0e SFe+v4Y9KGPYxGrmxbxYspmoDVwcEn5YCZOegGGAP4BPNMa8bbBWf9OmUUvufuv0wo td/7R0A4uUjWw== Date: Mon, 26 Jun 2023 13:15:29 +0100 From: Will Deacon To: "Ivan T. Ivanov" Cc: Mark Rutland , Catalin Marinas , Mark Brown , Shawn Guo , Dong Aisheng , Frank Li , Jason Liu , linux-arm-kernel@lists.infradead.org, linux-imx@nxp.com Subject: Re: [PATCH v2] arm64: errata: Add NXP iMX8QM workaround for A53 Cache coherency issue Message-ID: <20230626121528.GA19941@willie-the-truck> References: <20230420112952.28340-1-iivanov@suse.de> <20230602103436.GA16785@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230626_051537_120685_D098C3DB X-CRM114-Status: GOOD ( 27.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Mon, Jun 12, 2023 at 01:22:37PM +0300, Ivan T. Ivanov wrote: > On 06-12 10:33, Mark Rutland wrote: > > I'm saying that the *faulting logic* is local, not the broadcast. > > > > IIUC the erratum is due to the wiring between clusters losing some bits. The > > *recipient* of a broadcast DVM message (which is what TLBI or IC instructions > > will generate) will receive a bogus address (and other context) to use for the > > invalidate. > > > > The CPU which executes the `IC IVAU ` instruction will check the address in > > `` using its local MMU to determine whether the access should fault > > *before* sending the broadcast DVM message, and the recipients will not perform > > any MMU check (since e.g. they could be running a different process with a > > different VA space anyway). > > > > The MMU check is local to the CPU, and doesn't depend on any broadcast; that > > should be unaffected by the erratum. If that is affected then the erratum > > description is wrong and we have a bigger set of problems. > > > > Thanks, I think I get it. Now, what will be preferred way to fix IC > TLBI instructions for this errata? Using static_key for TLBI and > alternatives for IC instruction or something else? As I mentioned in a previous comment, I think this should use a static_key to drive the high-level behaviour instead of patching the low-level code with alternatives. > Keep trapping userspace IC instruction seems ok to me. Perhaps > alternative for IC in invalidate_icache_by_line macro? About > TLBI, it will be really invasive if static_key is used, I think. > Yes, there is over invalidation, but still overall performance of > SoC is almost doubled because of enabled 2 CA72 :-) > > Another point is, should I keep hunk in arm-smmu.c, because > cpus_have_final_cap() is not generally available for drivers? What do you mean here? We obviously can't break the build, but I think the easiest thing to do is add a clause to `arm_smmu_sva_supported()` to return false if this erratum is present. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel