public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: tip-bot for Lianbo Jiang <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: bjorn.helgaas@gmail.com, linux-kernel@vger.kernel.org,
	wang.yi59@zte.com.cn, hpa@zytor.com, luto@amacapital.net,
	lijiang@redhat.com, mingo@kernel.org, bp@suse.de, bhe@redhat.com,
	akpm@linux-foundation.org, thomas.lendacky@amd.com,
	dyoung@redhat.com, mingo@redhat.com, gustavo@embeddedor.com,
	x86@kernel.org, peterz@infradead.org, tglx@linutronix.de
Subject: [tip:x86/kdump] x86/crash: Add e820 reserved ranges to kdump kernel's e820 table
Date: Thu, 20 Jun 2019 03:01:10 -0700	[thread overview]
Message-ID: <tip-980621daf368f2b9aa69c7ea01baa654edb7577b@git.kernel.org> (raw)
In-Reply-To: <20190423013007.17838-4-lijiang@redhat.com>

Commit-ID:  980621daf368f2b9aa69c7ea01baa654edb7577b
Gitweb:     https://git.kernel.org/tip/980621daf368f2b9aa69c7ea01baa654edb7577b
Author:     Lianbo Jiang <lijiang@redhat.com>
AuthorDate: Tue, 23 Apr 2019 09:30:07 +0800
Committer:  Borislav Petkov <bp@suse.de>
CommitDate: Thu, 20 Jun 2019 10:05:06 +0200

x86/crash: Add e820 reserved ranges to kdump kernel's e820 table

At present, when using the kexec_file_load() syscall to load the kernel
image and initramfs, for example:

  kexec -s -p xxx

the kernel does not pass the e820 reserved ranges to the second kernel,
which might cause two problems:

 1. MMCONFIG: A device in PCI segment 1 cannot be discovered by the
kernel PCI probing without all the e820 I/O reservations being present
in the e820 table. Which is the case currently, because the kdump kernel
does not have those reservations because the kexec command does not pass
the I/O reservation via the "memmap=xxx" command line option.

Further details courtesy of Bjorn Helgaas¹: I think you should regard
correct MCFG/ECAM usage in the kdump kernel as a requirement. MMCONFIG
(aka ECAM) space is described in the ACPI MCFG table. If you don't have
ECAM:

  (a) PCI devices won't work at all on non-x86 systems that use only
   ECAM for config access,

  (b) you won't be able to access devices on non-0 segments (granted,
  there aren't very many of these yet, but there will be more in the
  future), and

  (c) you won't be able to access extended config space (addresses
  0x100-0xfff), which means none of the Extended Capabilities will be
  available (AER, ACS, ATS, etc).

 2. The second issue is that the SME kdump kernel doesn't work without
the e820 reserved ranges. When SME is active in the kdump kernel, those
reserved regions are still decrypted, but because those reserved ranges
are not present at all in kdump kernel's e820 table, they are accessed
as encrypted. Which is obviously wrong.

 [1]: https://lkml.kernel.org/r/CABhMZUUscS3jUZUSM5Y6EYJK6weo7Mjj5-EAKGvbw0qEe%2B38zw@mail.gmail.com

 [ bp: Heavily massage commit message. ]

Suggested-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Baoquan He <bhe@redhat.com>
Cc: Bjorn Helgaas <bjorn.helgaas@gmail.com>
Cc: dave.hansen@linux.intel.com
Cc: Dave Young <dyoung@redhat.com>
Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: kexec@lists.infradead.org
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: x86-ml <x86@kernel.org>
Cc: Yi Wang <wang.yi59@zte.com.cn>
Link: https://lkml.kernel.org/r/20190423013007.17838-4-lijiang@redhat.com
---
 arch/x86/kernel/crash.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 576b2e1bfc12..32c956705b8e 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -381,6 +381,12 @@ 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 e820 reserved ranges */
+	cmd.type = E820_TYPE_RESERVED;
+	flags = IORESOURCE_MEM;
+	walk_iomem_res_desc(IORES_DESC_RESERVED, flags, 0, -1, &cmd,
+			   memmap_entry_callback);
+
 	/* Add crashk_low_res region */
 	if (crashk_low_res.end) {
 		ei.addr = crashk_low_res.start;

  reply	other threads:[~2019-06-20 10:01 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-23  1:30 [PATCH 0/3 v11] add reserved e820 ranges to the kdump kernel e820 table Lianbo Jiang
2019-04-23  1:30 ` [PATCH 1/3 v11] x86/e820, resource: add a new I/O resource descriptor 'IORES_DESC_RESERVED' Lianbo Jiang
2019-06-20  9:59   ` [tip:x86/kdump] x86/e820, ioport: Add a new I/O resource descriptor IORES_DESC_RESERVED tip-bot for Lianbo Jiang
2019-04-23  1:30 ` [PATCH 2/3 v11] x86/mm: change the check condition in SEV because a new descriptor is introduced Lianbo Jiang
2019-06-20 10:00   ` [tip:x86/kdump] x86/mm: Rework ioremap resource mapping determination tip-bot for Lianbo Jiang
2019-04-23  1:30 ` [PATCH 3/3 v11] x86/kexec_file: add reserved e820 ranges to kdump kernel e820 table Lianbo Jiang
2019-06-20 10:01   ` tip-bot for Lianbo Jiang [this message]
2019-05-28  7:30 ` [PATCH 0/3 v11] add reserved e820 ranges to the " lijiang
2019-06-07 17:42   ` Borislav Petkov
2019-06-08  3:54     ` Baoquan He
2019-06-08  9:10       ` Borislav Petkov
2019-06-08 10:01         ` Baoquan He
2019-06-08 10:06           ` Borislav Petkov
2019-06-08 10:26             ` Baoquan He
2019-06-10 11:37               ` Borislav Petkov
2019-06-12  1:14                 ` lijiang
2019-06-12  1:55                 ` Baoquan He
2019-06-12  5:49                   ` Dave Young
2019-06-12 15:10                   ` Borislav Petkov
2019-06-12 16:52                     ` Lendacky, Thomas
2019-06-12 18:07                       ` Borislav Petkov
2019-06-12 19:10                         ` Lendacky, Thomas
2019-06-13 15:07                           ` Baoquan He
2019-06-13  1:18                         ` dyoung
2019-06-09  4:02     ` lijiang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tip-980621daf368f2b9aa69c7ea01baa654edb7577b@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=bjorn.helgaas@gmail.com \
    --cc=bp@suse.de \
    --cc=dyoung@redhat.com \
    --cc=gustavo@embeddedor.com \
    --cc=hpa@zytor.com \
    --cc=lijiang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=wang.yi59@zte.com.cn \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox