Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7818324imu; Thu, 15 Nov 2018 01:56:46 -0800 (PST) X-Google-Smtp-Source: AJdET5esEpmWZWPKSmKkkHu6oFjI6uKJudKu4YIiR4nNZuu92emMR6TTYo3u715utfIYVTC3R5Mm X-Received: by 2002:a62:995c:: with SMTP id d89-v6mr5664827pfe.11.1542275806063; Thu, 15 Nov 2018 01:56:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542275806; cv=none; d=google.com; s=arc-20160816; b=P73tAo3ja473Cr1CmfdducFMuTrwauiNW+ABybwvGr6YKkZIWPLEwUUZNHT4XwKNgt mmpBNknt/8OC2f9rN8zKlNrmLnj1FYdoK/XQpIXjbrGvEkGdjhyLqL/2b3bYDhN4GWtD nrtIvfICl8aavUMkEv8nKBcUzJtSyq9rMxfV8v3y2DDj7kEsQo9quTlQpBb6aGlm4sRZ 7bP72fhv6SzWXBPNwUt1Ye6hdIUiFrOBkTzek79ADZv/wzmh5FjJy02JMcwkQY3WuQ2G Ao87uZpSv8qrg3K/MBvTpb74KypX50q7TnlKPJQZPmv7fgAFiHACI3Bv5CxQEOToGV2T AmTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=tJMc8QtD6D1M2khubqkYICv4V5ECy6+1H1mlrVU7BAk=; b=mOtTNS6+eStM0swbc4dECr5Lbtk2QgSdvch6OLfLIOWD68bf61gRT10RC4mrQAOkRl 1Zb9USXkWSoNj9KvLEffepT+8sp+fjLch/Xa8nysoFMwMHxo7iGIwzK94ejUJp7o51dm TtAUay8g6/ZYre/ujG324kxrxkyrUI2tWSadHmXj/c0EKFlvl7Y6WDdV1DUC0m+cU7Sv NSVzEw4Yzw9uMHw4C5jnZCNzPfHT17wlQ3OivgwLxrrbA7MtpqmwbrU9pe933Oj8u4Ub hHLe65FqeVsH0bovoVVNLlrvHRgTM9c2o/jaWdchsFJJ4VeeyrJ0xicQQtWxkzB2DTGW hICg== 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 c17si20766625pgl.385.2018.11.15.01.56.31; Thu, 15 Nov 2018 01:56:46 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387742AbeKOUCs (ORCPT + 99 others); Thu, 15 Nov 2018 15:02:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39970 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728609AbeKOUCs (ORCPT ); Thu, 15 Nov 2018 15:02:48 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0BAD33002716; Thu, 15 Nov 2018 09:55:41 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-12-127.pek2.redhat.com [10.72.12.127]) by smtp.corp.redhat.com (Postfix) with ESMTP id C6CEC19C65; Thu, 15 Nov 2018 09:55:33 +0000 (UTC) From: Lianbo Jiang To: linux-kernel@vger.kernel.org Cc: kexec@lists.infradead.org, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, akpm@linux-foundation.org, dyoung@redhat.com, bhe@redhat.com Subject: [PATCH 0/2 v7] add reserved e820 ranges to the kdump kernel e820 table Date: Thu, 15 Nov 2018 17:55:27 +0800 Message-Id: <20181115095529.21220-1-lijiang@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Thu, 15 Nov 2018 09:55:41 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org These patches add the new I/O resource descriptor 'IORES_DESC_RESERVED' for the iomem resources search interfaces and also pass the e820 reserved ranges to kdump kernel. At present, when use the kexec_file_load syscall to load the kernel image and initramfs(for example: kexec -s -p xxx), the upstream kernel does not pass the e820 reserved ranges to the second kernel, which might cause two problems: The first one is the MMCONFIG issue, although which does not make the system crash or hang, this issue is still a potential risk, and also might lead to the hot-plug device could not be recognized in kdump kernel. Because the PCI MMCONFIG(extended mode) requires the reserved region otherwise it falls back to legacy mode. For example, the kdump kernel outputs the following log. Example: ...... [ 19.798354] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) [ 19.800653] [Firmware Info]: PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] not reserved in ACPI motherboard resources [ 19.800995] PCI: not using MMCONFIG ...... The correct kernel log is like this: ...... [ 0.082649] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) [ 0.083610] PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820 ...... The second issue is that the e820 reserved ranges do not setup in kdump kernel, which will cause some functions that related to the e820 reserved ranges to become invalid. For example: early_memremap()-> early_memremap_pgprot_adjust()-> memremap_should_map_decrypted()-> e820__get_entry_type() Please focus on these functions, early_memremap_pgprot_adjust() and memremap_should_map_decrypted(). In the first kernel, these ranges sit in e820 reserved ranges, so the memremap_should_map_decrypted() will return true, that is to say, the reserved memory is decrypted, then the early_memremap_pgprot_adjust() will call the pgprot_decrypted() to clear the memory encryption mask. In the second kernel, because the e820 reserved ranges are not passed to the second kernel, these ranges don't sit in the e820 reserved ranges, so the memremap_should_map_decrypted() will return false, that is to say, the reserved memory is encrypted, and then the early_memremap_pgprot_ adjust() will also call the pgprot_encrypted() to set the memory encryption mask. In fact, in the second kernel, the e820 reserved memory is still decrypted. Obviously, it has gone wrong. So, this issue must be fixed, otherwise kdump won't work in this case. The e820 reserved range is useful in kdump kernel, so it is necessary to pass the e820 reserved ranges to kdump kernel. Changes since v1: 1. Modified the value of flags to "0", when walking through the whole tree for e820 reserved ranges. Changes since v2: 1. Modified the value of flags to "0", when walking through the whole tree for e820 reserved ranges. 2. Modified the invalid SOB chain issue. Changes since v3: 1. Dropped [PATCH 1/3 v3] resource: fix an error which walks through iomem resources. Please refer to this commit <010a93bf97c7> "resource: Fix find_next_iomem_res() iteration issue" Changes since v4: 1. Improve the patch log, and add kernel log. Changes since v5: 1. Rewrite these patches log. Changes since v6: 1. Modify the [PATCH 1/2], and add the new I/O resource descriptor 'IORES_DESC_RESERVED' for the iomem resources search interfaces. 2. Modify the [PATCH 2/2], and walk through io resource based on the new descriptor 'IORES_DESC_RESERVED'. Lianbo Jiang (2): resource: add the new I/O resource descriptor 'IORES_DESC_RESERVED' x86/kexec_file: add reserved e820 ranges to kdump kernel e820 table arch/x86/kernel/crash.c | 6 ++++++ arch/x86/kernel/e820.c | 2 +- include/linux/ioport.h | 1 + 3 files changed, 8 insertions(+), 1 deletion(-) -- 2.17.1