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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 232F9C433DF for ; Tue, 30 Jun 2020 08:55:01 +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 DEA92206BE for ; Tue, 30 Jun 2020 08:55:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="2dYsbKv/"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="YEMFuEXO"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Tmid0dMc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DEA92206BE 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+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:References:Message-ID: Subject: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=qMeI7vnTmTvDH+EhrWT6552uqWiT4xk5aLmEgws28kA=; b=2dYsbKv//EGoZFFSzswDFz2nM gf3Z5irPgh1nEvE5RqogmlCQlKbhzIkEOg/Nl87QhEDQTuzI6aAtg1rHEgVvCze//oJY6QNqsTWbP IvPUf4KOyDqytWbTQ32H7c/SpuVSU9r9sv9PVUQTZ5CEJE8lQF745wIWStJj4+kOMxMAthQ+H+dz2 ChGuSYoCbA/yREqvNZzZi/C17bJDp5JaKWqUZtareDmp08Yfa48QDzjiecKZ4TgRsj+X41WX0+Egu A2EQEmTstOpJxhu0q79nAQEQR0aMq+6NZ65t82z2zD3w/u4DmkewJgsUMcx2grPMMKtZMh9/OJc3A KENXXL09Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqC1D-0001C1-Ls; Tue, 30 Jun 2020 08:53:31 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqC1B-0001Bq-E4 for linux-arm-kernel@merlin.infradead.org; Tue, 30 Jun 2020 08:53:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=mavAQYYIcbCbFiS0RfGKCq8eLGRUrKHJC77pDMihZqc=; b=YEMFuEXOFzV0Pdu5aOVZZHzg5/ HyA8k+Zf7is0q3FKsCAbVGfx0ICANWcKciGEA5qTIBNhc6Z7I0AY/CZvYpW169CrgQxT30csENSUb vxbj+tHTl4POMIkwYk4jCspVtCX8FVltQ9DRejVfs9uiEdfSUV49WCVpxHdi6ZGjaBndd8m2wVezK jtjyq2tC+piEhyBc1VcEinfGbHYrWpiNZgzzYarD+2VTG+XwKuCqoxrxTCyJoP5uoDvs6vzfDUpRk xhVu7Olul6do+GjJTX8UJw0wmqjbPtQvg3paejAxOsLZ008DhQqcrDF9S5c/RVIyVAGJWAMMfakoY azvzg0KA==; Received: from mail.kernel.org ([198.145.29.99]) by casper.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqBkh-0000X2-JC for linux-arm-kernel@lists.infradead.org; Tue, 30 Jun 2020 08:36:30 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (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 D1E7E206BE; Tue, 30 Jun 2020 08:36:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593506184; bh=qVv0jm35GqfwBo/fF/CPzQ3HSCMLWdEnYUNPHgaj5w4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Tmid0dMc6IQyRLotSKuO1ji7BOeVj3LyAfJeXTM7n9mWOBOGo/xxmSQxlyh7VRvdn KK5rSHoTxp4nwLMm5RGtUTj7Nm7XbL0MTZ+iZfd2o96+IQCgV+WzXdS+6NbfJTIGK8 HiteLuALKItTrdgn1jHlxDFeWImMK+6L1M+Obqps= Date: Tue, 30 Jun 2020 09:36:19 +0100 From: Will Deacon To: Marc Zyngier Subject: Re: [PATCH 2/2] arm64: Add workaround for Arm Cortex-A77 erratum 1508412 Message-ID: <20200630083618.GA13574@willie-the-truck> References: <20200629213321.2953022-1-robh@kernel.org> <20200629213321.2953022-2-robh@kernel.org> 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-20200630_093628_311240_AAC8997F X-CRM114-Status: GOOD ( 24.32 ) 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: Rob Herring , Jose.Marinho@arm.com, Suzuki K Poulose , Catalin Marinas , James Morse , Julien Thierry , kvmarm@lists.cs.columbia.edu, 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 [+Jose] On Tue, Jun 30, 2020 at 09:15:15AM +0100, Marc Zyngier wrote: > On 2020-06-29 22:33, Rob Herring wrote: > > On Cortex-A77 r0p0 and r1p0, a sequence of a non-cacheable or device > > load > > and a store exclusive or PAR_EL1 read can cause a deadlock. > > > > The workaround requires a DMB SY before and after a PAR_EL1 register > > read > > and the disabling of KVM. KVM must be disabled to prevent the > > problematic > > sequence in guests' EL1. This workaround also depends on a firmware > > counterpart to enable the h/w to insert DMB SY after load and store > > exclusive instructions. See the errata document SDEN-1152370 v10 [1] for > > more information. Jose -- having an SMC interface to see if the firmware is holding up its side of the bargian would be really helpful here. There's been one in development for _months_ now; any update? > This seems a bit extreme. Given that this CPU is most likely > used in big-little systems, there is still a bunch of CPUs > on which we could reliably execute guests. It is also likely > that people could run trusted guests. > > I would suggest printing a big fat warning and taining the > kernel with TAINT_CPU_OUT_OF_SPEC, together with the required > DSBs in the KVM code. Honestly, I think a TAINT is pointless here and we shouldn't be in the business of trying to police what people do with their systems when there's absolutely nothing we can do to help them. After all, they can always disable KVM themselves if they want to. The only sensible action you can take on seeing the taint is to disable the workaround to get rid of it, which is also the worst thing you can do! As another example, imagine if we had the ability to detect whether or not firmware was setting the patch registers. If we knew that it wasn't applying the workaround, would we TAINT on entering userspace? I don't think so. We'd probably just print a message when trying to apply the workaround, indicating that it was incomplete and the system may deadlock. Finally, we have another erratum that allows guests to deadlock the system (Cortex-A57 832075) so ultimately it's up to the person deploying the system to decide whether or not they can tolerate the risk of deadlock. In many cases, it won't be an issue, but if it is and they require KVM, then the part is dead in the water and Linux can't help with that. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel