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 659BFCD11BF for ; Fri, 22 Mar 2024 15:55:55 +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=/gySPK/btfqToFs3clacJ/qAT7GLD8Y0AsUi2/uHgMU=; b=aV5cOihaazhArm JTpyqHb2FWZtCO8+3pjF1wK4wK5FI3uMB3MjrwaMZUPV6LBFlh33HNiOjDQHfH4itBvTBqXUoZuhY BkL9/1cjR+1Rf/E29l44y6e9DgRW9eZibOCIKugBIQaQwkQTOoI9SUqdwd/hrcPzW4BH2rAH/TD6B 5zcDpeyG8tGbe4ieQZYdXCHGVDwlGWhRTk192vlNaIlHxygnra5Mh0Zl/ZQUKn/9BexlD5P1DkGWk 16AxTKTvY65Iqirsly6kdkGhLSQqCyJux6On0FI6Ml64FstXZibyL1a2F2LCCaCa6PIVaNg/JHlN8 Vs/ht6vO+CngCqx6fg+g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnhF9-00000007q0l-1IRg; Fri, 22 Mar 2024 15:55:43 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnhF6-00000007pyg-1F8X for linux-arm-kernel@lists.infradead.org; Fri, 22 Mar 2024 15:55:41 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 525EBCE182E; Fri, 22 Mar 2024 15:55:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BDB1DC43390; Fri, 22 Mar 2024 15:55:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711122934; bh=KBxbC04wRzWWwKvLE9KMw4YX1znbdo8yfBBNgMOfrII=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sjwCIOQa4pcZ9lcWhOvJXf7sUt7tYQ0s7MDOdyVy7+NPkDN7E0HpkRFLsAeINXqP1 Qk020GAQ6KK+5cI572KTCPOfrW5YZcaHcSmNLBCK8f51BA5FCSsKSQpHnpP9iiyzJO 9ulMVTEY3wdUE8bqK90PrE4DFVp/J7LMBq5yJtipiWLHklZ5tWcxm/aXUGqb9ZWlRq Jz3jIjiKH0nHLUJdLpFJEyc+Ji2LuRp5QGQrGK45C0bI66WQoupjR7jTejbxF24thL oaHtxiYe0VExQdZhGS1LYIvfQe/Bc6Ct4fDRv/QvqUVJSwiq5xM34li0mnAhf8SmeM 8nA+ZSE9F/7Vg== Date: Fri, 22 Mar 2024 15:55:29 +0000 From: Will Deacon To: Jason Gunthorpe Cc: Robin Murphy , Tyler Hicks , 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: <20240322155529.GE5634@willie-the-truck> References: <120d0dec-450f-41f8-9e05-fd763e84f6dd@arm.com> <20240319154756.GB2901@willie-the-truck> <20240319175007.GC66976@ziepe.ca> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240319175007.GC66976@ziepe.ca> 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-20240322_085540_632688_5F2D5D6E X-CRM114-Status: GOOD ( 13.22 ) 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 Hey Jason, On Tue, Mar 19, 2024 at 02:50:07PM -0300, Jason Gunthorpe wrote: > On Tue, Mar 19, 2024 at 03:47:56PM +0000, Will Deacon wrote: > > > 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? > > For whatever reason (and I really don't like this design) alot of work > was done on x86 so that device continues to work as-was right up until > the crash kernel does the first DMA operation. Including having the > crash kernel non disruptively inherit and retain the IOMMU > configuration. (eg see translation_pre_enabled() stuff in intel > driver) Right, I'm also not thrilled about trying to implement that :) What we have at the moment seems to be good enough to avoid folks complaining about it. For the case Tyler is reporting, though, I _think_ it's just a standard kexec() rather than a crashkernel. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel