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 4AB86C369D1 for ; Sun, 27 Apr 2025 12:23:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=D/IJKbWyjScen3G95LMpN0nx3W9d4pBtsp5COkTPWho=; b=hN6XFyZ+eXAqVvKYpuoSNyU5tr ez0iS4L509qX/SqQk89JKromP1aiUDod8+t+MF4zrFs2ksXMWIt2jKwCSMLOzLf0vMYlguYgJDeRo BAn5/HyyiJC0+zLVwGD69H/8YqlgmNcmqmptIHXs7cKwBRAxtfdbhAEmhQGgrkBL0PuAmimrGGFbp W6bJqGGvgwmjRD3B8SiK15xwcfq8u38RE7s0re9RnZbjFnZINA/ddFGPTjQiCVZVx6ThZ8x9nmZmD WbdBJMONLZK9ZlhwTrX5SkTVTME6LBvhgjEn6uANP/WbayqKRWK6VvOqySIw+E8r5KQummZ3PQUT8 XvmPUQPA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1u912X-00000003TaU-3BSp; Sun, 27 Apr 2025 12:23:21 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1u910b-00000003TTV-3pBz for linux-arm-kernel@lists.infradead.org; Sun, 27 Apr 2025 12:21:23 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 50C6842B97; Sun, 27 Apr 2025 12:21:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A76FC4CEE3; Sun, 27 Apr 2025 12:21:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745756480; bh=qgR2lz3v3NjAxknpyrFWkaL7/bhQwLOU/tYgivfTSX4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XWQ8KECxSqdvcp0sL5nci/HcxJBQ9cMd8jZsZOy+5vCNBuICJhnuoSM0hN4Zvkn9o ZcRXK7xE3yXvb9HbhD0i8sH3+o336Ic7QwGjMbQr5qVXf5nCgn77ELHE0N46tHlrHf lfRu+4a7odTFME8AhUdMG0PGZidoWHoGd1h7YpOPkjcByZnzR3GxpU/Y2dmB6+Drz9 9dfzsRHXLAXP7ba/6fVX8uzDbuIgoop1wkdZHmlPX1PX1CCZm6euVKOCKOS7HmU1PB gI6dHnlIYGmdmHYQ8cUsbdO1St7JLNwU6M5tI4FVsFcsY+xZJSCCpa7vwQNRKwtG/F EZdL2ivuJHM0Q== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1u910X-009GIf-FL; Sun, 27 Apr 2025 13:21:17 +0100 Date: Sun, 27 Apr 2025 13:21:16 +0100 Message-ID: <86frhtkd6r.wl-maz@kernel.org> From: Marc Zyngier To: D Scott Phillips Cc: Catalin Marinas , James Clark , James Morse , Joey Gouly , Kevin Brodsky , Mark Brown , Mark Rutland , Oliver Upton , "Rob Herring (Arm)" , Shameer Kolothum , Shiqi Liu , Will Deacon , Yicong Yang , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, open list Subject: Re: [PATCH 1/2] arm64: errata: Work around AmpereOne's erratum AC03_CPU_36 In-Reply-To: <86frhx9ex6.fsf@scott-ph-mail.amperecomputing.com> References: <20250415154711.1698544-1-scott@os.amperecomputing.com> <86wmbkk1yz.wl-maz@kernel.org> <86frhx9ex6.fsf@scott-ph-mail.amperecomputing.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: scott@os.amperecomputing.com, catalin.marinas@arm.com, james.clark@linaro.org, james.morse@arm.com, joey.gouly@arm.com, kevin.brodsky@arm.com, broonie@kernel.org, mark.rutland@arm.com, oliver.upton@linux.dev, robh@kernel.org, shameerali.kolothum.thodi@huawei.com, shiqiliu@hust.edu.cn, will@kernel.org, yangyicong@hisilicon.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250427_052121_990566_1925FBC3 X-CRM114-Status: GOOD ( 31.90 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 25 Apr 2025 03:02:29 +0100, D Scott Phillips wrote: > > Marc Zyngier writes: > > > On Tue, 15 Apr 2025 16:47:10 +0100, > > D Scott Phillips wrote: > >> > >> AC03_CPU_36 can cause asynchronous exceptions to be routed to the wrong > >> exception level if an async exception coincides with an update to the > >> controls for the target exception level in HCR_EL2. On affected > >> machines, always do writes to HCR_EL2 with async exceptions blocked. > > > > From the actual errata document [1]: > > > > > > If an Asynchronous Exception to EL2 occurs, while EL2 software is > > changing the EL2 exception control bits from a configuration where > > asynchronous exceptions are routed to EL2 to a configuration where > > asynchronous exceptions are routed to EL1, the processor may exhibit > > the incorrect exception behavior of routing an interrupt taken at EL2 > > to EL1. The affected system register is HCR_EL2, which contains > > control bits for routing and enabling of EL2 exceptions. > > > > > > My reading is that things can go wrong when clearing the xMO bits. > > > > I don't think we need to touch the xMO bits at all when running > > VHE. So my preference would be to: > > > > - simply leave the xMO bits set at all times (nothing bad can happen > > from that, can it?) > > > > - prevent these systems from using anything but VHE (and fail KVM init > > otherwise) > > Hi Marc, I started writing up this patch and then realized that the > issue can also not happen in nvhe mode. While xMO bits are modified > there, async exceptions are always masked and so the "simultaneously > take an async exception" part of the erratum can't happen. > > Does that sound right to you, or are there cases that I'm missing. If > it's right the nvhe is also can't hit the erratum case, then what do you > think is the right thing for me to do here? That's an interesting point. We always run the nVHE/hVHE hypervisor code with interrupts disabled by virtue of taking an HVC exception into EL2, so that particular case seems OK as it literally implements the proposed workaround. However, there's at least one catch: the SError handling code in hyp/entry.S relies on clearing PSTATE.A to take a pending abort (the so-called VAXorcism). I take that this CPU implements FEAT_RAS, and that we don't need to worry about this code path either, and that the erratum cannot trigger on speculatively executed paths? If we're OK with that, then I don't think there is much to do, other than always setting the xMO bits at all times, for which I already have a patch in review (v2 coming shortly). M. -- Without deviation from the norm, progress is not possible.