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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 7805BC433DF for ; Mon, 1 Jun 2020 07:40:12 +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 2C430206E2 for ; Mon, 1 Jun 2020 07:40:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="N8E4AaMx"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="pTdQwku6" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C430206E2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:References: Message-ID:Subject: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=Il+nbzREkkZ+7qh/AvBjyoecHVzmuNKbVWsl1+DiV4I=; b=N8E4AaMxwYlBj8 x/NPQveQtsQPPLZa76nxR3SWmAcXe1XAaWxrjthWRjlnAeygfb/cQLRGNCqGegIooPCh3qiWgJvNk tF1Z4F+ZLn5o0g3TFxdzrZR71YocnMepqDpeDN90EirOQuL8K0POBikydlYMhxLNDQJLNJxO43cmG 9JF+Q3M8Ub7KJ+07KVQQ5mw2f1MjEqnlzTTAXAgY5hw1u9cxK7q6d4xYfdoRsRkTRe9eReuqq40xY SYNdVyD/pwPT6+8OQmCM6qlsx6/IHwA6pJpi5HgOvEKnuLrJYkQ9EmRprYgL7TB1GWZCrjuccjK0m 4gsxU6tvtEg8fhH73DqA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jff3J-0002LY-5D; Mon, 01 Jun 2020 07:40:09 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jff3D-0001IL-9C; Mon, 01 Jun 2020 07:40:05 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 622A0206E2; Mon, 1 Jun 2020 07:40:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590997203; bh=FyHcyMF4ZlnF9cw2o7B84pnPHILgJlC+50CCvUgnec8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pTdQwku6NU00KgX+IldtXNs16JG0B50epi1ji/FpWCgG9JZe+d7USE9Sar6ZnKua/ x72VMDhp9emZJM1d7h4+WnrzwRoWTaiS/Nmktueo9X4AelfP1vrMj3Yxh9TXNnTVZr bp/w7w9ccmr2cgMdbtACUGqGJwF4YLM+iLSDHVPw= Date: Mon, 1 Jun 2020 08:39:58 +0100 From: Will Deacon To: Prabhakar Kushwaha Subject: Re: [PATCH][v2] iommu: arm-smmu-v3: Copy SMMU table for kdump kernel Message-ID: <20200601073957.GD8601@willie-the-truck> References: <1589251566-32126-1-git-send-email-pkushwaha@marvell.com> <20200518155545.GO32394@willie-the-truck> <20200521092311.GB5091@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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-20200601_004003_372231_1D468CF7 X-CRM114-Status: GOOD ( 23.88 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ganapatrao Prabhakerrao Kulkarni , Marc Zyngier , Bhupesh Sharma , kexec mailing list , Bjorn Helgaas , Prabhakar Kushwaha , 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 Thu, May 21, 2020 at 04:52:02PM +0530, Prabhakar Kushwaha wrote: > On Thu, May 21, 2020 at 2:53 PM Will Deacon wrote: > > > > On Tue, May 19, 2020 at 08:24:21AM +0530, Prabhakar Kushwaha wrote: > > > On Mon, May 18, 2020 at 9:25 PM Will Deacon wrote: > > > > On Mon, May 11, 2020 at 07:46:06PM -0700, Prabhakar Kushwaha wrote: > > > > > @@ -3272,6 +3281,23 @@ static int arm_smmu_init_l1_strtab(struct arm_smmu_device *smmu) > > > > > return 0; > > > > > } > > > > > > > > > > +static void arm_smmu_copy_table(struct arm_smmu_device *smmu, > > > > > + struct arm_smmu_strtab_cfg *cfg, u32 size) > > > > > +{ > > > > > + struct arm_smmu_strtab_cfg rdcfg; > > > > > + > > > > > + rdcfg.strtab_dma = readq_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE); > > > > > + rdcfg.strtab_base_cfg = readq_relaxed(smmu->base > > > > > + + ARM_SMMU_STRTAB_BASE_CFG); > > > > > + > > > > > + rdcfg.strtab_dma &= STRTAB_BASE_ADDR_MASK; > > > > > + rdcfg.strtab = memremap(rdcfg.strtab_dma, size, MEMREMAP_WB); > > > > > + > > > > > + memcpy_fromio(cfg->strtab, rdcfg.strtab, size); > > > > > + > > > > > > this need a fix. It should be memcpy. > > > > > > > > + cfg->strtab_base_cfg = rdcfg.strtab_base_cfg; > > > > > > > > Sorry, but this is unacceptable. These things were allocated by the DMA API > > > > so you can't just memcpy them around and hope for the best. > > > > > > > > > > I was referring copy_context_table() in drivers/iommu/intel-iommu.c. > > > here i see usage of memremap and memcpy to copy older iommu table. > > > did I take wrong reference? > > > > > > What kind of issue you are foreseeing in using memcpy(). May be we can > > > try to find a solution. > > > > Well the thing might not be cache-coherent to start with... > > > > Thanks for telling possible issue area. Let me try to explain why > this should not be an issue. > > kdump kernel runs from reserved memory space defined during the boot > of first kernel. kdump does not touch memory of the previous kernel. > So no page has been created in kdump kernel and there should not be > any data/attribute/coherency issue from MMU point of view . Then how does this work?: rdcfg.strtab = memremap(rdcfg.strtab_dma, size, MEMREMAP_WB); You're explicitly asking for a write-back mapping. > During SMMU probe functions, dmem_alloc_coherent() will be used > allocate new memory (part of existing flow). > This patch copy STE or first level descriptor to *this* memory, after > mapping physical address using memremap(). > It just copy everything so there should not be any issue related to > attribute/content. > > Yes, copying done after mapping it as MEMREMAP_WB. if you want I can > use it as MEMREMAP_WT You need to take into account whether or not the device is coherent, and the DMA API is designed to handle that for you. But even then, this is fragile as hell because you end up having to infer the hardware configuration from the device to understand the size and format of the data structures. If the crashkernel isn't identical to the host kernel (in terms of kconfig, driver version, firmware tables, cmdline etc) then this is very likely to go wrong. That's why I think that you need to reinitialise any devices that want to do DMA. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel