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 35454C54E71 for ; Fri, 22 Mar 2024 15:52:18 +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=FdCNWRyV1Y+88KzALetkxOzG9DAVXEdWZKoiwtr7I7M=; b=zh2ypSJWVB5yEi evrP771Lk5zpp8aZ0rj0PCdNdNVQBuBuH7e7jW7XkrKU3Xw/qWo4V1NPSdGvh2XBXS2F6HbIIjz/5 CCToxXx7FpDmYmHFPQR7T5NFDT8OmsUkJxh1oT8TZu/tnUBaicM1uc1cXEG3hJ5+LAF79xqib0Gvf QNv7dqOXmlc6eNPaxW6lHJNVEeVmLU9xd41MOnjAYeKNwZn+0/P29ysgksxBkAKlFm1Uh+ix2yKgA nKTiuK/CWKDxpbsBE2/ssLXdRtCiQYkuz3t/POeZYgxnE2skrQnfmErTUKDYCWrluIxM5cXDyVBQk Ma/mKZ9lruSexPTrn4+Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnhBg-00000007pT0-0Hlr; Fri, 22 Mar 2024 15:52:08 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnhBc-00000007pSF-3c3c for linux-arm-kernel@lists.infradead.org; Fri, 22 Mar 2024 15:52:06 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 974F860C24; Fri, 22 Mar 2024 15:52:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3439FC433F1; Fri, 22 Mar 2024 15:52:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711122723; bh=a9x0EjWyPdwufxgTEjOLoHdDlBCO8EawXvsde+dmWeI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=i9cSUxp8ZpIaCT3GAK0ljz4aaFQiOh8lWr7QbjXiQWGqvohorTAQ3bfaTZ9VWhyrK ZJbRUrIFWyi/EhtRHlBVNvjYEN7KmNYZO6KO8SBWMYO8XICuGNJoD95TIsox7wWhZQ Qt0gevJauPkZ42w7AfvqdolJJQ2RoympO2lhgD5h+y+jdigNwb/5Rs+EV3acskoXen fRMzThDcSIGhiGKfZBfPtPLMpZt9IFJhliLwp8swnGVWOlOXRnVL9i1EqxDRM+fLKp cy/UmhjPIG6VeCIvbLEYBqcLf0Isi1pUwTFjJI85U/X8q1IWF6sqsBsoWMOkZG9hR1 l5s2EUWeIGXWw== Date: Fri, 22 Mar 2024 15:51:57 +0000 From: Will Deacon To: Robin Murphy Cc: Tyler Hicks , 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: <20240322155157.GD5634@willie-the-truck> References: <120d0dec-450f-41f8-9e05-fd763e84f6dd@arm.com> <20240319154756.GB2901@willie-the-truck> <5b19ab13-a7a0-48e2-99a4-357a9f4aeafa@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5b19ab13-a7a0-48e2-99a4-357a9f4aeafa@arm.com> 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_085204_967665_F750F8FE X-CRM114-Status: GOOD ( 17.31 ) 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 Tue, Mar 19, 2024 at 06:17:39PM +0000, Robin Murphy wrote: > In terms of the shutdown behaviour, I think it actually works out as-is. For > the normal case we haven't touched GBPA, so we are truly returning to the > boot-time condition; in the unexpected case where SMMUEN was already enabled > then we'll go into an explicit GPBA abort state, but that seems a > not-unreasonable compromise for not preserving the entire boot-time Stream > Table etc., whose presence kind of implies it wouldn't have been bypassing > everything anyway. > > The more I look at the remaining aspect of disable_bypass for controlling > broken-DT behaviour the more I suspect it can't actually be useful either > way, especially not since default domains. I have no memory of what my > original reasoning might have been, so I'm inclined to just rip that all out > and let probe fail. I see no reason these days not to expect a broken DT to > leads to a broken system, especially not now with DTSchema validation. That sounds reasonable to me, although we may end up having to back it out if we regress systems with borked firmware :( > Then there's just the kdump warning it suppresses, of which I also have no > idea why it's there either, but apparently that one's on you :P I think _that_ one is because the previous (crashed) kernel won't have torn anything down, so there could be active DMA using translations in the SMMU. In that case, the crashkernel (which is running from some carveout) may find the SMMU enabled, but it really can't stick it into bypass mode because that's likely to corrupt random memory. So in that case, we do stick it into abort before we reinitialise it and then we disabling fault reporting altogether to avoid the log spam: if (is_kdump_kernel()) enables &= ~(CR0_EVTQEN | CR0_PRIQEN) Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel