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 69412C54E71 for ; Tue, 19 Mar 2024 19:15:16 +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=doX7rtuwLcGU6vRDCS4s0SOeOePJMcRK7EfqPbLnVKM=; b=XVrt7mXu8itaod rSDZdPSO7AzIPtx7eE5P5Zet+WsJ1x9yoCJ+J92G5LFMuEotmGLATC8DpHGTF7/n7Npn+pxhh0Bv0 oSi+yArQTowDeYfz/ilwrq1463lqYaq36nq4COxfrggn6g/R8o5/Vc1wLaaf7eMBARGXK/mk48k+I TEXtRFWFnplITlapTfZnMWQr2vY5a/a/ucHl9nphAYKwqVUGvFAcZrN4bcu3YT81Q/80EhaSrGsmF yNFsS2L8j9+q1qhjo41NODjRDi3r6JJdUD+6ZLtsqAWysLNAmkDC34lkfgZJn89nS0SelwMxN1xV1 b2215qx908gjBOoaGfxA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rmevP-0000000Dws2-07K2; Tue, 19 Mar 2024 19:15:03 +0000 Received: from wfhigh6-smtp.messagingengine.com ([64.147.123.157]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rmevL-0000000DwqK-2tM5 for linux-arm-kernel@lists.infradead.org; Tue, 19 Mar 2024 19:15:01 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfhigh.west.internal (Postfix) with ESMTP id A358618000E5; Tue, 19 Mar 2024 15:14:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 19 Mar 2024 15:14:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tyhicks.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1710875693; x=1710962093; bh=xGm0zjbmfX bFVPto+4v59X+3OdhXgzvRm9zT7AK86qM=; b=f1typ6jn+tQliNPQM72wKjsL1u DjfH4ga5pkmBPdskzl0IKbxNf6nHgJxvg/951gNak26e22y60wFeVz0KZBizRcz8 7mpIvvpmAhYnv+G8hE/z+NzIADNl0MLSbCv2CUSscbVAuJ9BcUgkyW21sE5ohO3V pxFb7kQVFb1uWQt1rMRGbyrjCPHGXuCjt3Ryx8kJLc2Lafy50d6qY+cfyl+VHa+/ CXqtgKV0bPhB1uUpu4kSMZd5rViLCQvdjIjmWEFSLfuIbn6eAj5yDzIqBcmwWdNl 17H1pW5a3AIWqy/5eq2gQfZMqrZZzsk8SOxb2q0mid+kCik6tF7uoD27CyZw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1710875693; x=1710962093; bh=xGm0zjbmfXbFVPto+4v59X+3OdhX gzvRm9zT7AK86qM=; b=w+/WRv1B/tsfZrLuXlkBJ5oNBUCnmDhL/0dffSylcdj3 c9BKFmjgww9P2Geix0ok8jLU3IUKXfPX8pgdNatKHAOTXe/VTlJumvucK2dWuKzM b3epcnVFhgwXBUDaTMTE4OsqE3f1t8wnzxaC3o5xEWiUWY7nS6oA0LQNP25wzesV VPUdGEwNTRAU7yYlm1ZTNhn5kE54OMfvjXJ8RYFa54pkuGsrGPB+UKFTTwgTnrI5 gc90Gm6NoO9A8HmZZ+YqH7BraaWeQTpb8vytc8L6yrjq4cZLBJqTvZCdEaiqEXER ODyiLhGeZC1TS7F2cJA88FJsVyo8Wc2f0bW7NvovpQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrledtgdeliecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefvhihlvghr ucfjihgtkhhsuceotghouggvsehthihhihgtkhhsrdgtohhmqeenucggtffrrghtthgvrh hnpedvhedvtddthfefhfdtgfelheefgefgudejueevkeduveekvdegjedttdefgfelieen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtohguvg esthihhhhitghkshdrtghomh X-ME-Proxy: Feedback-ID: i78e14604:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 19 Mar 2024 15:14:51 -0400 (EDT) Date: Tue, 19 Mar 2024 14:14:26 -0500 From: Tyler Hicks To: Will Deacon Cc: Robin Murphy , Jason Gunthorpe , Jerry Snitselaar , linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Dexuan Cui , Easwar Hariharan Subject: Re: Why is the ARM SMMU v1/v2 put into bypass mode on kexec? Message-ID: References: <120d0dec-450f-41f8-9e05-fd763e84f6dd@arm.com> <20240319154756.GB2901@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240319154756.GB2901@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240319_121500_022098_697FE698 X-CRM114-Status: GOOD ( 17.71 ) 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 2024-03-19 15:47:56, Will Deacon wrote: > On Tue, Mar 19, 2024 at 12:57:52PM +0000, Robin Murphy wrote: > > Beyond properly quiescing and resetting the system back to a boot-time > > state, the outgoing kernel in a kexec can only really do things which affect > > itself. Sure, we *could* configure the SMMU to block all traffic and disable > > the interrupt to avoid getting stuck in a storm of faults on the way out, > > but what does that mean for the incoming kexec payload? That it can have the > > pleasure of discovering the SMMU, innocently enabling the interrupt and > > getting stuck in an unexpected storm of faults. Or perhaps just resetting > > the SMMU into a disabled state and thus still unwittingly allowing its > > memory to be corrupted by the previous kernel not supporting kexec properly. > > Right, it's hard to win if DMA-active devices weren't quiesced properly > by the outgoing kernel. Either the SMMU was left in abort (leading to the > problems you list above) or the SMMU is left in bypass (leading to possible > data corruption). Which is better? My thoughts are that a loud and obvious failure (via unidentified stream fault messages and/or a possible interrupt storm preventing the new kernel from booting) is favorable to silent and subtle data corruption of the target kernel. > The best solution is obviously to implement those missing ->shutdown() > callbacks. Completely agree here but it can be difficult to even identify that a missing ->shutdown hook is the root cause without code changes to put the SMMU into abort mode and sleep for a bit in the SMMU's ->shutdown hook. Tyler _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel