From patchwork Mon Mar 18 13:12:42 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Leizhen \(ThunderTown\)" X-Patchwork-Id: 160491 Delivered-To: patch@linaro.org Received: by 2002:a02:5cc1:0:0:0:0:0 with SMTP id w62csp2643903jad; Mon, 18 Mar 2019 06:14:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqy1BuUslPbJuZzdm6l/7XB1ObcVI71e1BmB+3g5L/ck+0uMJmRLk1Zpdd6BnIaTlBEEFeAW X-Received: by 2002:a63:ee58:: with SMTP id n24mr17356275pgk.247.1552914877184; Mon, 18 Mar 2019 06:14:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552914877; cv=none; d=google.com; s=arc-20160816; b=bF6j6XoheX0W8xX3bZrsHdjSHIWiv8z23J/Gnzxe/n+HwkaVcnujdiL7Kzhk0++KFK CPxInCnymPZfQL+QwrGYipSwzXEQjG9c/9zdnrrCe96Ilj25Fi0Lr3FzT2ChVuv0l4pH HxDFtoTw4IiA3biu/OTWpKIkJDTtgjMwZ3vznPXtxgApvYd34W+yt0ZXX/1Slv4lafLI GuLaw0dmI/OPH9CtedhkF/J6EOEbSxRLY7ImmOZw5pBGvc0Gfvd82PolaMqcjxiYp3mu Q4zzr0xX2MgrUWaZSnMAM9EJTqCs94TrDDPade9lhtGvBeRQDdXoqqNF4fcALk6fsYf1 jwYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=1shit6Owa0u7qzITRLCxafF+YcwlIuNBM5U/wupQwYo=; b=ajM2poSUxCAGsezK/2PCgQ9YFY5A1ue6G1WWnwz5OnezboPPRnUNyyn6HnfuaD9J6b mP6BT2PW/wlA6na164B0Xp5zFu+IIL3IhHXN0al6poUYeOniiDufUk5Ep6VAevy62JQV wxuci7wZaDUyA2Syt1pVCXygi6KSZpZasn2sCvAATwEwSz7u6XOP5B7Ya3QMkhC0OqJE 995J9SP30pL5jCbqwITlUtuiLq5clMVQ1evBFS3oY0gmt7MoXcIGb619ZvrU6bieccWo UxVyx/nYJntlVDTzLzXf1RhzlHkEHRs3urF1S486rh9OxFWI1m/g4b+c+GTYKAublqrs 6Ghw== 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 y8si9183332plp.385.2019.03.18.06.14.36; Mon, 18 Mar 2019 06:14:37 -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 S1727457AbfCRNOa (ORCPT + 31 others); Mon, 18 Mar 2019 09:14:30 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:52242 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726093AbfCRNO3 (ORCPT ); Mon, 18 Mar 2019 09:14:29 -0400 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id C67FACB25BD9615062DA; Mon, 18 Mar 2019 21:14:27 +0800 (CST) Received: from HGHY1l002753561.china.huawei.com (10.177.23.164) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.408.0; Mon, 18 Mar 2019 21:14:16 +0800 From: Zhen Lei To: Jean-Philippe Brucker , Robin Murphy , Will Deacon , Joerg Roedel , linux-arm-kernel , iommu , linux-kernel CC: Zhen Lei Subject: [PATCH v2 1/2] iommu/arm-smmu-v3: make sure the stale caching of L1STD are invalid Date: Mon, 18 Mar 2019 21:12:42 +0800 Message-ID: <20190318131243.20716-2-thunder.leizhen@huawei.com> X-Mailer: git-send-email 2.19.2.windows.1 In-Reply-To: <20190318131243.20716-1-thunder.leizhen@huawei.com> References: <20190318131243.20716-1-thunder.leizhen@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.177.23.164] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org After the content of L1STD(Level 1 Stream Table Descriptor) in DDR has been modified, should make sure the cached copies be invalidated. Signed-off-by: Zhen Lei --- drivers/iommu/arm-smmu-v3.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) -- 1.8.3 diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c index d3880010c6cfc8c..9b6afa8e69f70f6 100644 --- a/drivers/iommu/arm-smmu-v3.c +++ b/drivers/iommu/arm-smmu-v3.c @@ -1071,13 +1071,14 @@ static void arm_smmu_write_ctx_desc(struct arm_smmu_device *smmu, *dst = cpu_to_le64(val); } -static void arm_smmu_sync_ste_for_sid(struct arm_smmu_device *smmu, u32 sid) +static void __arm_smmu_sync_ste_for_sid(struct arm_smmu_device *smmu, + u32 sid, bool leaf) { struct arm_smmu_cmdq_ent cmd = { .opcode = CMDQ_OP_CFGI_STE, .cfgi = { .sid = sid, - .leaf = true, + .leaf = leaf, }, }; @@ -1085,6 +1086,16 @@ static void arm_smmu_sync_ste_for_sid(struct arm_smmu_device *smmu, u32 sid) arm_smmu_cmdq_issue_sync(smmu); } +static void arm_smmu_sync_ste_for_sid(struct arm_smmu_device *smmu, u32 sid) +{ + __arm_smmu_sync_ste_for_sid(smmu, sid, true); +} + +static void arm_smmu_sync_std_for_sid(struct arm_smmu_device *smmu, u32 sid) +{ + __arm_smmu_sync_ste_for_sid(smmu, sid, false); +} + static void arm_smmu_write_strtab_ent(struct arm_smmu_device *smmu, u32 sid, __le64 *dst, struct arm_smmu_strtab_ent *ste) { @@ -1232,6 +1243,7 @@ static int arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid) arm_smmu_init_bypass_stes(desc->l2ptr, 1 << STRTAB_SPLIT); arm_smmu_write_strtab_l1_desc(strtab, desc); + arm_smmu_sync_std_for_sid(smmu, sid); return 0; } From patchwork Mon Mar 18 13:12:43 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Leizhen \(ThunderTown\)" X-Patchwork-Id: 160490 Delivered-To: patch@linaro.org Received: by 2002:a02:5cc1:0:0:0:0:0 with SMTP id w62csp2643817jad; Mon, 18 Mar 2019 06:14:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqzN3ut+BYwJJooBpqmHc35OkwU4lQCmzVYzC+c/CQtgmkFGNDSIpmqxQYc2n5qKpcd6nPGN X-Received: by 2002:a17:902:7289:: with SMTP id d9mr19741770pll.314.1552914872584; Mon, 18 Mar 2019 06:14:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552914872; cv=none; d=google.com; s=arc-20160816; b=Rv7vlgiJU1iAL4/+qxNaCvbd4sz8IewDlCQliK5iEzh1NUf4KELpda7XPwGA5M3tzA 0nsRKncC0xGpU7Ft9oZa8JSFm2a7fhRQW5oymavgOx0GacEyxgW4uCYF9PSTImJ4iDRl lqlqz4RT5YdsPTu2sefg5UsyA6nUvGv8AkmzJ2AHaKkFZwxgzX2fT+2GgRVsnY7yJP0y EfH79rMDwJPOX3kioKGcQA3W+zIRE/+5dGPKjTEfNArZQscKbJ1AAd+X79mBxLj6inGq 94RnV7EgITFaQvYshO/HuO9ab8Zk6k/iUMRoKq1Ay0xN8ZQqNupXUr6w9pGKJ3FUdaAU 4rTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=iSieAapcn50RLcGlrvmsXfbyP8c3xtVs5TbU3/MuKKU=; b=hfHolj6K0oRTQDW+R860wqFzAlh1vfLtLqTXG766JhxWOryYYqjgnY6f17Nj5UGjDw mD78ERS7/UD+pbaDxAmY7OOMJGImX5R7y05x3vbvvYGoxCdDCeNeXJHQV/QRK/Ew6yAp QSDa7pKXVaYDKjj1jA2Lk5giwKnQCc/paCJBtqZVWsqKJGj7MwukYgK6tzMR2iFj8Xc4 8p/EdWWZKt0F80/JkVBB4cBsi7mcEbsmcVykPOPnW9xvP8bCNbDIG4gKHyyt2EKkdBO+ 2MjZN8vGlNCn63fJ30+yriBzwtAETyJHb45ZhKZ9nhrK8o5sJGWxevqWSx/9dRa3N/lb WmPg== 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 l11si9818433pgc.473.2019.03.18.06.14.32; Mon, 18 Mar 2019 06:14:32 -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 S1727640AbfCRNOb (ORCPT + 31 others); Mon, 18 Mar 2019 09:14:31 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:52246 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727257AbfCRNO3 (ORCPT ); Mon, 18 Mar 2019 09:14:29 -0400 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id CDF98E8185D9CA8E2875; Mon, 18 Mar 2019 21:14:27 +0800 (CST) Received: from HGHY1l002753561.china.huawei.com (10.177.23.164) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.408.0; Mon, 18 Mar 2019 21:14:17 +0800 From: Zhen Lei To: Jean-Philippe Brucker , Robin Murphy , Will Deacon , Joerg Roedel , linux-arm-kernel , iommu , linux-kernel CC: Zhen Lei Subject: [PATCH v2 2/2] iommu/arm-smmu-v3: to make smmu can be enabled in the kdump kernel Date: Mon, 18 Mar 2019 21:12:43 +0800 Message-ID: <20190318131243.20716-3-thunder.leizhen@huawei.com> X-Mailer: git-send-email 2.19.2.windows.1 In-Reply-To: <20190318131243.20716-1-thunder.leizhen@huawei.com> References: <20190318131243.20716-1-thunder.leizhen@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.177.23.164] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I don't known why device_shutdown() is not called in the first kernel before the execution switch to the secondary kernel. People may afraid that the function may lead the kernel to be crashed again, because it contains too many operations, lead the secondary kernel can not be entered finally. Maybe the configuration of a device driver is set in the first kernel, but it's not set in the secondary kernel, because of the limited memory resources. (In order to facilitate the description, mark this kind of devices as "unexpected devices".) Because the device was not shutdown in the first kernel, so it may still access memory in the secondary kernel. For example, a netcard may still using its ring buffer to auto receive the external network packets in the secondary kernel. commit b63b3439b856 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel") set SMMU_GBPA.ABORT to abort the unexpected devices access, but it also abort the memory access of the devices which we needed, like netcard. For example, a system may have no harddisk, and the vmcore should be dumped through network. In fact, we can use STE.config=0b000 to abort the memory access of the unexpected devices only. Show as below: 1. In the first kernel, all buffers used by the "unexpected" devices are correctly mapped, and it will not be corrupted by the secondary kernel because the latter has its dedicated reserved memory. 2. Enter the secondary kernel, set SMMU_GBPA.ABORT=1 then disable smmu. 3. Preset all STE entries: STE.config=0b000. For 2-level Stream Table, pre-allocated a dummy L2ST(Level 2 Stream Table) and make all L1STD.l2ptr pointer to the dummy L2ST. The dummy L2ST is shared by all L1STDs(Level 1 Stream Table Descriptor). 4. Enable smmu. After now, a new attached device if needed, will allocate a new L2ST accordingly, and change the related L1STD.l2ptr pointer to it. Please note that, we still base desc->l2ptr to judge whether the L2ST have been allocated or not, and don't care the value of L1STD.l2ptr. Fixes: commit b63b3439b856 ("iommu/arm-smmu-v3: Abort all transactions ...") Signed-off-by: Zhen Lei --- drivers/iommu/arm-smmu-v3.c | 72 ++++++++++++++++++++++++++++++++------------- 1 file changed, 51 insertions(+), 21 deletions(-) -- 1.8.3 diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c index 9b6afa8e69f70f6..28b04d4aef62a9f 100644 --- a/drivers/iommu/arm-smmu-v3.c +++ b/drivers/iommu/arm-smmu-v3.c @@ -1218,35 +1218,57 @@ static void arm_smmu_init_bypass_stes(u64 *strtab, unsigned int nent) } } -static int arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid) +static int __arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid, + struct arm_smmu_strtab_l1_desc *desc) { - size_t size; void *strtab; struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg; - struct arm_smmu_strtab_l1_desc *desc = &cfg->l1_desc[sid >> STRTAB_SPLIT]; - if (desc->l2ptr) - return 0; - - size = 1 << (STRTAB_SPLIT + ilog2(STRTAB_STE_DWORDS) + 3); strtab = &cfg->strtab[(sid >> STRTAB_SPLIT) * STRTAB_L1_DESC_DWORDS]; - desc->span = STRTAB_SPLIT + 1; - desc->l2ptr = dmam_alloc_coherent(smmu->dev, size, &desc->l2ptr_dma, - GFP_KERNEL | __GFP_ZERO); if (!desc->l2ptr) { - dev_err(smmu->dev, - "failed to allocate l2 stream table for SID %u\n", - sid); - return -ENOMEM; + size_t size; + + size = 1 << (STRTAB_SPLIT + ilog2(STRTAB_STE_DWORDS) + 3); + desc->l2ptr = dmam_alloc_coherent(smmu->dev, size, + &desc->l2ptr_dma, + GFP_KERNEL | __GFP_ZERO); + if (!desc->l2ptr) { + dev_err(smmu->dev, + "failed to allocate l2 stream table for SID %u\n", + sid); + return -ENOMEM; + } + + desc->span = STRTAB_SPLIT + 1; + arm_smmu_init_bypass_stes(desc->l2ptr, 1 << STRTAB_SPLIT); } - arm_smmu_init_bypass_stes(desc->l2ptr, 1 << STRTAB_SPLIT); arm_smmu_write_strtab_l1_desc(strtab, desc); + return 0; +} + +static int arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid) +{ + int ret; + struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg; + struct arm_smmu_strtab_l1_desc *desc = &cfg->l1_desc[sid >> STRTAB_SPLIT]; + + ret = __arm_smmu_init_l2_strtab(smmu, sid, desc); + if (ret) + return ret; + arm_smmu_sync_std_for_sid(smmu, sid); return 0; } +static int arm_smmu_init_dummy_l2_strtab(struct arm_smmu_device *smmu, u32 sid) +{ + static struct arm_smmu_strtab_l1_desc dummy_desc; + + return __arm_smmu_init_l2_strtab(smmu, sid, &dummy_desc); +} + /* IRQ and event handlers */ static irqreturn_t arm_smmu_evtq_thread(int irq, void *dev) { @@ -2149,8 +2171,12 @@ static int arm_smmu_init_l1_strtab(struct arm_smmu_device *smmu) } for (i = 0; i < cfg->num_l1_ents; ++i) { - arm_smmu_write_strtab_l1_desc(strtab, &cfg->l1_desc[i]); - strtab += STRTAB_L1_DESC_DWORDS << 3; + if (is_kdump_kernel()) { + arm_smmu_init_dummy_l2_strtab(smmu, i << STRTAB_SPLIT); + } else { + arm_smmu_write_strtab_l1_desc(strtab, &cfg->l1_desc[i]); + strtab += STRTAB_L1_DESC_DWORDS << 3; + } } return 0; @@ -2466,11 +2492,8 @@ 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()) { + 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"); } @@ -2858,6 +2881,13 @@ static int arm_smmu_device_probe(struct platform_device *pdev) struct device *dev = &pdev->dev; bool bypass; + /* + * Force to disable bypass in the kdump kernel, abort all incoming + * transactions from the unknown devices. + */ + if (is_kdump_kernel()) + disable_bypass = 1; + smmu = devm_kzalloc(dev, sizeof(*smmu), GFP_KERNEL); if (!smmu) { dev_err(dev, "failed to allocate arm_smmu_device\n");