From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) by kanga.kvack.org (Postfix) with ESMTP id 9E7266B0005 for ; Mon, 4 Jan 2016 06:04:42 -0500 (EST) Received: by mail-io0-f179.google.com with SMTP id q21so150786539iod.0 for ; Mon, 04 Jan 2016 03:04:42 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id b63si19760799ioe.200.2016.01.04.03.04.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Jan 2016 03:04:42 -0800 (PST) Date: Mon, 4 Jan 2016 19:04:27 +0800 From: Dave Young Subject: Re: [PATCH v2 14/16] x86,nvdimm,kexec: Use walk_iomem_res_desc() for iomem search Message-ID: <20160104110427.GA2965@dhcp-128-65.nay.redhat.com> References: <1451081365-15190-1-git-send-email-toshi.kani@hpe.com> <1451081365-15190-14-git-send-email-toshi.kani@hpe.com> <20160104092545.GA7033@dhcp-128-65.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160104092545.GA7033@dhcp-128-65.nay.redhat.com> Sender: owner-linux-mm@kvack.org List-ID: To: Toshi Kani Cc: akpm@linux-foundation.org, bp@alien8.de, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dan Williams , x86@kernel.org, linux-nvdimm@ml01.01.org, kexec@lists.infradead.org On 01/04/16 at 05:25pm, Dave Young wrote: > Hi, Toshi, > > On 12/25/15 at 03:09pm, Toshi Kani wrote: > > Change to call walk_iomem_res_desc() for searching resource entries > > with the following names: > > "ACPI Tables" > > "ACPI Non-volatile Storage" > > "Persistent Memory (legacy)" > > "Crash kernel" > > > > Note, the caller of walk_iomem_res() with "GART" is left unchanged > > because this entry may be initialized by out-of-tree drivers, which > > do not have 'desc' set to IORES_DESC_GART. > > Found below commit which initialize the GART entry: > commit 56dd669a138c40ea6cdae487f233430d12372767 > Author: Aaron Durbin > Date: Tue Sep 26 10:52:40 2006 +0200 > > [PATCH] Insert GART region into resource map > > Patch inserts the GART region into the iomem resource map. The GART will then > be visible within /proc/iomem. It will also allow for other users > utilizing the GART to subreserve the region (agp or IOMMU). > > Signed-off-by: Aaron Durbin > > But later it was reverted: > commit 707d4eefbdb31f8e588277157056b0ce637d6c68 > Author: Bjorn Helgaas > Date: Tue Mar 18 14:26:12 2014 -0600 > > Revert "[PATCH] Insert GART region into resource map" > > This reverts commit 56dd669a138c, which makes the GART visible in > /proc/iomem. This fixes a regression: e501b3d87f00 ("agp: Support 64-bit > APBASE") exposed an existing problem with a conflict between the GART > region and a PCI BAR region. > > The GART addresses are bus addresses, not CPU addresses, and therefore > should not be inserted in iomem_resource. > > On many machines, the GART region is addressable by the CPU as well as by > an AGP master, but CPU addressability is not required by the spec. On some > of these machines, the GART is mapped by a PCI BAR, and in that case, the > PCI core automatically inserts it into iomem_resource, just as it does for > all BARs. > > Inserting it here means we'll have a conflict if the PCI core later tries > to claim the GART region, so let's drop the insertion here. > > The conflict indirectly causes X failures, as reported by Jouni in the > bugzilla below. We detected the conflict even before e501b3d87f00, but > after it the AGP code (fix_northbridge()) uses the PCI resource (which is > zeroed because of the conflict) instead of reading the BAR again. > > Conflicts: > arch/x86_64/kernel/aperture.c > > Fixes: e501b3d87f00 agp: Support 64-bit APBASE > Link: https://bugzilla.kernel.org/show_bug.cgi?id=72201 > Reported-and-tested-by: Jouni Mettala > Signed-off-by: Bjorn Helgaas > > > For amd64 agp, currently the region name is "aperture" instead: > drivers/char/agp/amd64-agp.c: agp_aperture_valid() > > This may not be the only case, but I doubt that anyone is testing this since > long time ago kexec-tools excluding the 'GART' region. Kexec-tools and kexec_file > may need update to use "aperture" if someone can test it. > > I think adding an enum value for compatibility is reasonable, we do not care > about third party drivers in mainline. Hmm, rethink about it, the new kernel will not export "GART" regions thus the in-kernel loader should never see such regions as long as there's no other drivers exporting it. Thus dropping the code chunk in crash.c about 'GART' should be fine. Thanks Dave -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org