Received: by 10.223.164.202 with SMTP id h10csp3594855wrb; Tue, 28 Nov 2017 14:00:34 -0800 (PST) X-Google-Smtp-Source: AGs4zMZt3143c8gzndQ83kt8rhGbsisMFsyn3ajd1XiHGnAhZVfhPOuMdXP2W+hIjYyS4owRZ7tT X-Received: by 10.98.109.65 with SMTP id i62mr607391pfc.139.1511906434483; Tue, 28 Nov 2017 14:00:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511906434; cv=none; d=google.com; s=arc-20160816; b=UE+tgry06msawtocdc4zWJuonSu0OMuiLqtLsdekWFeAkGF0N5HIrenn+KCvROfOrE rR5DzdsLf2HkaIv2I02+F9W2A3f4eFGRTMNr5aQWxJ1QOmbNfFQSGAeT8y0ej1negjQO eMbaDd7zs+Jy/5CN2fdgvG1YkhXtmq6QNrBbn5MguTx7FLthWrqYIlk2fJopMyWTt9OM bhHrHfDuYvlEw18TlTrnYjDPfEBrcpyKJ4FwgowiuDEWdrCg+dkCaw4h//ZmmMsENEsa pZR9CU0B/MaPAOPsFNutl1YWTYMwd2w8sYpydByYkgxSgcp+shK3dOQFS38ALA3vauD7 Rd9A== 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:arc-authentication-results; bh=P0VRRKGasmr5L96JBShrss3yXkowy3a07oOSpCkQrLc=; b=RufrbWGVEAED74VpgKaOJVbMKoffjbXq0QTBwFw9dmsLh64k07bccol0he59TUl1wQ cwfxWiWTfou16IXQpQET2ZCt+w+e5bw6T2COXSuh90/+T4Ewt4N05z0SBENfw3/AnkFj O/2K2nQFb8EI+d0gvLc7yuwda4R6QwKWcjTNAvIzT6tioP3/cOax/6UYV2QuA6liULPa WcVyF2N2UDSoPAv+hjfo3S1LwqZ7yCkKzlbTKDR1Q3TBTeKaTzudh/jcqczwjBczdNFO hiWn0vowOCpvD1eqGYQbcJUBV9uIFP7LL5WXL0a2+frRxzSivF2bRZTwXOx5SbxQSAEq 2/vg== 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 v4si113443plo.211.2017.11.28.14.00.22; Tue, 28 Nov 2017 14:00:34 -0800 (PST) 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 S1753300AbdK1V6h (ORCPT + 70 others); Tue, 28 Nov 2017 16:58:37 -0500 Received: from mx2.suse.de ([195.135.220.15]:39346 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752468AbdK1V6g (ORCPT ); Tue, 28 Nov 2017 16:58:36 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id E5EBAAE5D; Tue, 28 Nov 2017 21:58:34 +0000 (UTC) Date: Tue, 28 Nov 2017 22:58:33 +0100 From: Jiri Bohac To: Baoquan He Cc: yinghai@kernel.org, joro@8bytes.org, Bjorn Helgaas , Toshi Kani , David Airlie , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Thomas Gleixner , Dave Young , Vivek Goyal Subject: Re: [PATCH] x86/kexec: Exclude GART aperture from vmcore Message-ID: <20171128215833.hhcjvn5qjfc3bdrk@dwarf.suse.cz> References: <20171103172822.4ty6yjhewroe4z4j@dwarf.suse.cz> <20171106024143.GA3669@x1> <20171106090155.p7jhe2m57whfxma3@dwarf.suse.cz> <20171106092729.GB3669@x1> <20171106095638.7iwlyjmlom3tqelt@dwarf.suse.cz> <20171107113956.GC3669@x1> <20171107134212.tmjdt7rdailtbosa@dwarf.suse.cz> <20171107153428.ex27nwkvelhm2nm7@dwarf.suse.cz> <20171112080426.GB6429@x1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171112080426.GB6429@x1> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Baoquan, On Sun, Nov 12, 2017 at 04:04:26PM +0800, Baoquan He wrote: > Solution: > 1) Remove the code which support GART IOMMU when it's not enabled in > BIOS. This has been done in the new generation of hardware IOMMU like > intel vt-d IOMMU and amd-Vi IOMMU. We should not make GART IOMMU be > exceptional. Wouldn't this break old machines with actual AGP and misconfigured/bugg BIOSes? Wasn't that the reason why we have the workaround of mapping the hole over real memory? > 2) Remove those pages from mm subsystem since they are not seen any more > though they have been added into mm subsystem, because CPU can't see > them. not exactly sure I understand this... they are reserved by the memblock allocater, thus preventing any further use by any mm code. > 3) Remove the apreture region from /proc/iomem so that pages in that > region can't be seen by kdump kernel. This is easier, but just a work > around. I like this idea, but won't this cause pci_claim_resource() fail after the call to pci_find_parent_resource() ? See my previous mail. Bad thing is, we don't want to break random old AGP hardware, but at the same time, it's now too rare to properly test this. So wouldn't it be better to fix the problem at least for the kexec_file case using my original patch? A possible hack for the old kexec syscall might be to make /proc/iomem list the "GART" region without it being present in the iomem resource database. kexec-tools has working code to deal with the GART region, but the kernel no longer includes it in /proc/iomem. Or maybe a cleaner solution than special-casing the "GART" region into /proc/iomem would be to introduce a new type of iomem resource that would be visible in /proc/iomem but would allow other resources to be requested even when overlapping the region of this special resource? This way, we could insert the "GART" resource when allocating the hole but later, when an actual AGP driver requests the range during PCI enumeration, the "GART" resource would be overwrtiten by the actual PCI resource. -- Jiri Bohac SUSE Labs, Prague, Czechia From 1583855513541086004@xxx Sun Nov 12 10:25:24 +0000 2017 X-GM-THRID: 1583066928846548446 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread