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 8FC8BC5475B for ; Thu, 14 Mar 2024 07:50:05 +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:MIME-Version: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:In-Reply-To:References: List-Owner; bh=XgaUcdb597SRwGD2QioMrSYK2G3KEoRqbXmRKZseVGY=; b=v7lppPY3zwA8uj ZiBS0bWzc6ceNb7tM+pTRZN9ZNrBza8n/Kl69PxhczJLTKI4/mpwI3MNEiZEBCMh55luo3g7Uy2VF 2v61/o3Y6rzs+ehrvXH3RS5auS+DlN/yjDGi46iVataVHhzow7ISEqJE/eJhSqqfDLW21B9kpAPOC wL1VmNAuFTS1fUPbL+oi0Hb18L88JB/Nq0xt3fuUXu+ayaNES7AOxuTpd0EVPTDIDiCc+Xkn4jOPs nmVDfsLZhwbNnLlEynqltuCYeR168+UJJImX5V3cSmhh7krmMIvabWDkmGJZSDGpofzEn03oQ8Alc 5W5qiw9M5GMv0QX3jfXg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rkfqZ-0000000DRgM-3aNj; Thu, 14 Mar 2024 07:49:52 +0000 Received: from fout5-smtp.messagingengine.com ([103.168.172.148]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rkfqO-0000000DRXP-07H9 for linux-arm-kernel@lists.infradead.org; Thu, 14 Mar 2024 07:49:43 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfout.nyi.internal (Postfix) with ESMTP id 4B594138006A; Thu, 14 Mar 2024 03:49:36 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 14 Mar 2024 03:49:36 -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 :message-id:mime-version:reply-to:subject:subject:to:to; s=fm1; t=1710402576; x=1710488976; bh=eFzKJGcTUwYXn5hAxNPYqKluD4AtrRYv x3RqPw+fqD4=; b=hBoLVHzWZMOW7v8w3KEqmi7MJDckEd0KLubqQak0nNxGSLq6 EZjdIkaPCTmXAOWQT4sEvg3UHwQ9Smq/9SS625opDwlDyr86wTdqKZq3UdpHrapf y+tAjTXcSoMbmhO7i+Ar9DqYq+k7HPZSfLvpJDKLAcUFSQZsnzJj3Fsp+5gUwwQB W2yKieZN30BFt4X5EOqrsiAid24owuJLgY7v5jC8qQhNLfFCTW/FsxYw8GRmxSvW 047rhipyCWqqntVCxKLyia/y+X/7eOwgPbdo2gaS4jgXJjGgM1FD/kY0VlEHMthk MVg87RKwwvqYEnyUmUBlae7idkBG5DLf3cIbMA== 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:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1710402576; x=1710488976; bh=eFzKJGcTUwYXn5hAxNPYqKluD4AtrRYvx3R qPw+fqD4=; b=khkqkkxhzgn+acuDvZ1+DmOf+Rlf7+40P5Uhd8HOdUmUkk342Mr 9/k6p4Ozp2XwoYQ29/U4fE+n9cBInFYeGgzkz+NaCBXbo94ZW2+54xseriUD/Ydy Ms17bGa93b+tPku77xZAIJ4qv/OpoIHOjWAVENayNGwsFGmgjpVegpKSyXcMiBb/ AAUhA3wAXHzYHuANXfiUg9DWZvINPhYhf+R3aM0B7jgvCkSh0vPn37Ej7vh3cPiJ +We1UcQXsHw7WzpiXETSYSuKmLu92xOVBI7YyWQUXzi+WPf8ESOnU8bFk2HZGIGj zRuwxP3cjuDEfkG4I18z6Kd7K7YzdxfNmng== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeeigddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugesthdtredttddtvdenucfhrhhomhepvfihlhgvrhcu jfhitghkshcuoegtohguvgesthihhhhitghkshdrtghomheqnecuggftrfgrthhtvghrnh epheekvdehveffvdefudefiefhveetieekvedvleetfedufffgfffhgfeggefhkeetnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheptghouggvse hthihhihgtkhhsrdgtohhm X-ME-Proxy: Feedback-ID: i78e14604:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 14 Mar 2024 03:49:35 -0400 (EDT) Date: Thu, 14 Mar 2024 02:49:20 -0500 From: Tyler Hicks To: Will Deacon , Robin Murphy , Jason Gunthorpe , Jerry Snitselaar Cc: linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Dexuan Cui , Easwar Hariharan Subject: Why is the ARM SMMU v1/v2 put into bypass mode on kexec? Message-ID: MIME-Version: 1.0 Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240314_004940_839942_CBAB7215 X-CRM114-Status: UNSURE ( 9.55 ) X-CRM114-Notice: Please train this message. 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 Given that drivers are only optionally asked to implement the .shutdown hook, which is required to properly quiesce devices before a kexec, why is it that we put the ARM SMMU v1/v2 into bypass mode in the arm-smmu driver's own .shutdown hook? arm_smmu_device_shutdown() -> set SMMU_sCR0.CLIENTPD bit to 1 Driver authors often forget to even implement a .shutdown hook, which results in some hard-to-debug memory corruption issues in the kexec'ed target kernel due to pending DMA operations happening on untranslated addresses. Why not leave the SMMU in translate mode but clear the stream mapping table (or maybe even call arm_smmu_device_reset()) in the SMMU's .shutdown hook to prevent the memory corruption from happening in the first place? Fully acknowledging that the proper fix is to quiesce the devices, I feel like resetting the SMMU and leaving it in translate mode across kexec would be more consistent with the intent behind v5.2 commit 954a03be033c ("iommu/arm-smmu: Break insecure users by disabling bypass by default"). The incoming transactions of devices, that weren't properly quiesced during a kexec, would be blocked until their drivers have a chance to reinitialize the devices in the new kernel. I appreciate any help understanding why bypass mode is utilized here as I'm sure there are nuances that I haven't considered. Thank you! Tyler _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel