Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp715528imm; Wed, 19 Sep 2018 05:54:54 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZxVcE30m/R1BxkJp00J9LZyXYPuLZAXCHwidi0ktpFIR1LF0OBlffYpFKQeXW7k5UWLzeH X-Received: by 2002:a63:7d7:: with SMTP id 206-v6mr33253541pgh.17.1537361694350; Wed, 19 Sep 2018 05:54:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537361694; cv=none; d=google.com; s=arc-20160816; b=e0vtaVEaHjpHKcEACnqhgedzRPuvv5vowrt9lOeXjzKleYhK/nb4SR+1qLrE9CnUSB UvsOBHU+Tugo2S+zBtin8eElfoAtlR6Qu43m+7kZ23tV28rGDOlpzQJcN68RPMxAVFgN KIqeC2+BOuAFR3sYl3/E7hGjfMM8YObFa+UyiWEROrgpNJe1/HnNKnghSo68cETnoyHk wI0370oulcac75yQKbOK2XMWHiY3zEbjBIPoD3LmNkPX4bVUtl6uOxF94EdrD6MjDxgS JYNkfDfQJ8s4WMpdSpLxUNU82eufsheGm+FUerSNNYLHxkr384OCvEAVJkhh1Soomksc 8B4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=PRASp64TcE9hgbeVKHpwvd1bGV3kVuEw0xspzpYziFE=; b=MRFDsmIs5pn2g8j+z4CI05Z9x8YeIP8lK509YPexaO59i7uBgaOc/wTEFm/0yJO5rM 7/fPtfihRG4X8AYxAaX0wceKNLuAweU7K20lb9MeuZ6n+g2aD7jMAvsPWP4MtQ7sJXa1 HLuvTifKBtWhY4csDzQ4fKtMCxHtq68KfFaiZhwoPVHldeNsiiHBKroFRCQuVe7fUVpa DBhDsUmNT/KKOGcNfATFmVfhNsiIz7f4C+X1mnUyIQEd+OC/ZFW6IgcBmoV4yebggGe7 IVAvIUh/QenWtKfH949pkE4e+Ve9NQneOWxTDFxm8WKVQzMCSgpB5TsNV87RV4+zxfmF PpIg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i5-v6si20442416pgk.200.2018.09.19.05.54.38; Wed, 19 Sep 2018 05:54:54 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731815AbeISSbh (ORCPT + 99 others); Wed, 19 Sep 2018 14:31:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5829 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731419AbeISSbh (ORCPT ); Wed, 19 Sep 2018 14:31:37 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7D0E73084038; Wed, 19 Sep 2018 12:53:48 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-12-52.pek2.redhat.com [10.72.12.52]) by smtp.corp.redhat.com (Postfix) with ESMTP id B30F75D96E; Wed, 19 Sep 2018 12:53:33 +0000 (UTC) From: Lianbo Jiang To: linux-kernel@vger.kernel.org Cc: kexec@lists.infradead.org, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, akpm@linux-foundation.org, dan.j.williams@intel.com, thomas.lendacky@amd.com, bhelgaas@google.com, baiyaowei@cmss.chinamobile.com, tiwai@suse.de, bp@suse.de, brijesh.singh@amd.com, dyoung@redhat.com Subject: [PATCH 3/3 v2] x86/kexec_file: add reserved e820 ranges to kdump kernel e820 table Date: Wed, 19 Sep 2018 20:52:51 +0800 Message-Id: <20180919125251.8181-4-lijiang@redhat.com> In-Reply-To: <20180919125251.8181-1-lijiang@redhat.com> References: <20180919125251.8181-1-lijiang@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Wed, 19 Sep 2018 12:53:48 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org E820 reserved ranges is useful in kdump kernel, we have added this in kexec-tools code. One reason is PCI mmconf (extended mode) requires reserved region otherwise it falls back to legacy mode. When AMD SME kdump support, it needs to map dmi table area as unencrypted. For normal boot these ranges sit in e820 reserved ranges thus the early ioremap code naturally map them as unencrypted. So if we have same e820 reserve setup in kdump kernel then it will just work like normal kernel. Signed-off-by: Dave Young Signed-off-by: Lianbo Jiang --- arch/x86/kernel/crash.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c index ae724a6e0a5f..3460be990e0c 100644 --- a/arch/x86/kernel/crash.c +++ b/arch/x86/kernel/crash.c @@ -384,6 +384,11 @@ int crash_setup_memmap_entries(struct kimage *image, struct boot_params *params) walk_iomem_res_desc(IORES_DESC_ACPI_NV_STORAGE, flags, 0, -1, &cmd, memmap_entry_callback); + /* Add all reserved ranges */ + cmd.type = E820_TYPE_RESERVED; + walk_iomem_res_desc(IORES_DESC_NONE, 0, 0, -1, &cmd, + memmap_entry_callback); + /* Add crashk_low_res region */ if (crashk_low_res.end) { ei.addr = crashk_low_res.start; -- 2.17.1