Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1322806yba; Thu, 4 Apr 2019 08:31:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqye4MSIOnpIVjmLjuD35zSJ+HmXE6oyGipPP1YYa8+mNIOpsBPn5vHA3/AFo03+uOvT6omq X-Received: by 2002:a17:902:2ba7:: with SMTP id l36mr6847530plb.237.1554391908495; Thu, 04 Apr 2019 08:31:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554391908; cv=none; d=google.com; s=arc-20160816; b=0nN0SN4k0W7ysVguVusLGuH7YeeaCH/y4MZmCYXJIXn/R3GRihX8v5qX+yKkJZWIEU yskCwWIPzC+ioXyHzx1N/3sIluVafQfoePjpFiDvoIQ6do8E/ojZZQlBgXb5zdxFZir7 a3FowHCJwwuOO28LNjiy1Y1DWXQqHfqSLXrjHv+LhlZl1l8N7nkQ7liSCe090WjAJ643 jLDJgbbECnIX3L/jqz83pnOzw6B9czg/IulxRmdUY/ATUMgpfK2eVP46v4Yx8WJqFuVn pdVlCEJMLXPPuuod0VJ0WRbhhp1844X/j+2QAIIY1gojcBgZ3K/gy4tmT8yybc5zbyux oXPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=jK1IEIYwFRTRNDEicUyyJqLClWZXhD1LpjUlfOszRyM=; b=GbkDB1MsZpnpRxt07H/WaqOGGmJ9tXCf91RWSJdFKTBV2En2Qi4jY4YWwZAld6LYpC YzQKftExO8HqfGV4EaIL8EKatACh4594QgLun+Qemlad1BGCQfinPQsvQDElmvLodqnc d1dzfPu7ovW5VpFcjoPg0GdXW1HeaSnHmEySc97xv6aAJgvR3nMmrp6Jqh8X/vCjH/LP 3Ex1cikjuAmUeZ9ykE5ZPECJfB7yMQdDovEqUplG2hgIci/NawbTAWYK5FKClaryfetw AZ44dmoYuBWWRYx8hMB8QKQ4Z0Wd9nh4F18d6gNX2njYQNWnMt/hvvLi1WVGzCaJsry7 mmnQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p10si16561225plq.152.2019.04.04.08.31.33; Thu, 04 Apr 2019 08:31:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728802AbfDDPag (ORCPT + 99 others); Thu, 4 Apr 2019 11:30:36 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:34262 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725904AbfDDPaf (ORCPT ); Thu, 4 Apr 2019 11:30:35 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 77B45169E; Thu, 4 Apr 2019 08:30:35 -0700 (PDT) Received: from fuggles.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 214603F59C; Thu, 4 Apr 2019 08:30:33 -0700 (PDT) Date: Thu, 4 Apr 2019 16:30:31 +0100 From: Will Deacon To: Zhen Lei Cc: Jean-Philippe Brucker , Robin Murphy , Joerg Roedel , linux-arm-kernel , iommu , linux-kernel Subject: Re: [PATCH v2 0/2] iommu/arm-smmu-v3: make sure the kdump kernel can work well when smmu is enabled Message-ID: <20190404153031.GE27558@fuggles.cambridge.arm.com> References: <20190318131243.20716-1-thunder.leizhen@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190318131243.20716-1-thunder.leizhen@huawei.com> User-Agent: Mutt/1.11.1+86 (6f28e57d73f2) () Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Zhen Lei, On Mon, Mar 18, 2019 at 09:12:41PM +0800, Zhen Lei wrote: > v1 --> v2: > 1. Drop part2. Now, we only use the SMMUv3 hardware feature STE.config=0b000 > (Report abort to device, no event recorded) to suppress the event messages > caused by the unexpected devices. > 2. rewrite the patch description. This issue came up a while back: https://lore.kernel.org/linux-pci/20180302103032.GB19323@arm.com/ and I'd still prefer to solve it using the disable_bypass logic which we already have. Something along the lines of the diff below? We're relying on the DMA API not subsequently requesting a passthrough domain, but it should only do that if you've configured your crashkernel to do so. Will --->8 diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c index d3880010c6cf..91b8f3b2ee25 100644 --- a/drivers/iommu/arm-smmu-v3.c +++ b/drivers/iommu/arm-smmu-v3.c @@ -2454,13 +2454,9 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu, bool bypass) /* Clear CR0 and sync (disables SMMU and queue processing) */ reg = readl_relaxed(smmu->base + ARM_SMMU_CR0); if (reg & CR0_SMMUEN) { - if (is_kdump_kernel()) { - arm_smmu_update_gbpa(smmu, GBPA_ABORT, 0); - arm_smmu_device_disable(smmu); - return -EBUSY; - } - dev_warn(smmu->dev, "SMMU currently enabled! Resetting...\n"); + WARN_ON(is_kdump_kernel() && !disable_bypass); + arm_smmu_update_gbpa(smmu, GBPA_ABORT, 0); } ret = arm_smmu_device_disable(smmu);