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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE2CCC282DA for ; Fri, 19 Apr 2019 13:49:28 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 8D4AC222C4 for ; Fri, 19 Apr 2019 13:49:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="A8JE+8nZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8D4AC222C4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=d2plTcQAx2GwIDS7UPRh7WjNwENJ3eHEzVR9onpMid8=; b=A8JE+8nZkweqRw JEvt5MjFppmZhugNDChsWCylZZkPkfBiLVz5Pgzf8TLyzU0mJYavSMYZbyzieg6pHjxGI1W1HmpF3 MW9lsoRPTt6lCZ1S2KkUX+B8Ltdh8jfRKFnwIi2w0UAnGvk8+p6L5AkEvIqzhX8tL/9+fchixfu9O 6og6um8ooL3SPXtrGIVsszu8efWnmmdoZOsrROMHc4ZyzIFLRiInTS51k06ct3D04VHEYIL27RNnh YkKea23NQ3azqdpFOaMvKGJ4co/MIEI6lHDMke2r/axRZ0bWXVXeT/ieiKuB6SRLcB7r+1r0XTsaR sBzo3yBFZGRk6lWsD0gA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hHTtH-0000XO-Du; Fri, 19 Apr 2019 13:49:19 +0000 Received: from szxga05-in.huawei.com ([45.249.212.191] helo=huawei.com) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hHTsT-0007tD-Jm for linux-arm-kernel@lists.infradead.org; Fri, 19 Apr 2019 13:48:32 +0000 Received: from DGGEMS409-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 33F1597439F0519A1287; Fri, 19 Apr 2019 21:48:11 +0800 (CST) Received: from [127.0.0.1] (10.177.23.164) by DGGEMS409-HUB.china.huawei.com (10.3.19.209) with Microsoft SMTP Server id 14.3.408.0; Fri, 19 Apr 2019 21:48:06 +0800 Subject: Re: [PATCH v2 0/2] iommu/arm-smmu-v3: make sure the kdump kernel can work well when smmu is enabled To: Will Deacon References: <20190318131243.20716-1-thunder.leizhen@huawei.com> <20190404153031.GE27558@fuggles.cambridge.arm.com> <5CAAB293.3080600@huawei.com> <20190416091410.GC31579@fuggles.cambridge.arm.com> <5CB683D2.9010901@huawei.com> From: "Leizhen (ThunderTown)" Message-ID: <5CB9D195.7000707@huawei.com> Date: Fri, 19 Apr 2019 21:48:05 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <5CB683D2.9010901@huawei.com> X-Originating-IP: [10.177.23.164] X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190419_064830_264240_0BF634DD X-CRM114-Status: GOOD ( 18.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jean-Philippe Brucker , Joerg Roedel , linux-kernel , iommu , Robin Murphy , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2019/4/17 9:39, Leizhen (ThunderTown) wrote: > > > On 2019/4/16 17:14, Will Deacon wrote: >> On Mon, Apr 08, 2019 at 10:31:47AM +0800, Leizhen (ThunderTown) wrote: >>> On 2019/4/4 23:30, Will Deacon wrote: >>>> 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? >>> >>> Yes, my patches also use disable_bypass=1(set ste.config=0b000). If >>> SMMU_IDR0.ST_LEVEL=0(Linear Stream table supported), then all STE entries >>> are allocated and initialized(set ste.config=0b000). But if SMMU_IDR0.ST_LEVEL=1 >>> (2-level Stream Table), we only allocated and initialized the first level tables, >>> but leave level 2 tables dynamic allocated. That means, C_BAD_STREAMID(eventid=0x2) >>> will be reported, if an unexpeted device access memory without reinitialized in >>> kdump kernel. >> >> So is your problem just that the C_BAD_STREAMID events are noisy? If so, >> perhaps we should be disabling fault reporting entirely in the kdump kernel. >> >> How about the update diff below? I'm keen to have this as simple as >> possible, so we don't end up introducing rarely tested, complex code on >> the crash path. > In theory, it can solve the problem, let me test it. Hi Will, I have tested your patch on my board today. It works well. > > But then again, below patch will also disable the fault reporting come from the > expected devices which are used in the kdump kernel. In fact, my patches have been > merged into our interval version more than 2 months, no bug have been found yet. > > However, my patches do not support the case that the hardware does not support the > "STE bypass" feature, I think your patch can also resolve it. > >> >> Will >> >> --->8 >> >> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c >> index d3880010c6cf..d8b73da6447d 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); >> @@ -2553,6 +2549,8 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu, bool bypass) >> return ret; >> } >> >> + if (is_kdump_kernel()) >> + enables &= ~(CR0_EVTQEN | CR0_PRIQEN); >> >> /* Enable the SMMU interface, or ensure bypass */ >> if (!bypass || disable_bypass) { >> >> . >> > -- Thanks! BestRegards _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel