All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lianbo Jiang <lijiang@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: kexec@lists.infradead.org, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, akpm@linux-foundation.org,
	dave.hansen@linux.intel.com, luto@kernel.org,
	peterz@infradead.org, x86@kernel.org, hpa@zytor.com,
	dyoung@redhat.com, bhe@redhat.com, Thomas.Lendacky@amd.com
Subject: [PATCH 3/3 v11] x86/kexec_file: add reserved e820 ranges to kdump kernel e820 table
Date: Tue, 23 Apr 2019 09:30:07 +0800	[thread overview]
Message-ID: <20190423013007.17838-4-lijiang@redhat.com> (raw)
In-Reply-To: <20190423013007.17838-1-lijiang@redhat.com>

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:

The first one is the MMCONFIG issue. The basic problem is that this
device is in PCI segment 1 and the kernel PCI probing can not find it
without all the e820 I/O reservations being present in the e820 table.
And 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. (This problem does not show up for other vendors, as SGI
is apparently the actually fails for everyone, but devices in segment 0
are then found by some legacy lookup method.) The workaround for this
is to pass the I/O reserved regions to the kdump kernel.

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 albe to access devices on
non-0 segments, (c) you won't be able to access extended config space(
address 0x100-0xffff), which means none of the Extended Capabilities will
be available(AER, ACS, ATS, etc). [Bjorn's comment]

The second issue is that the SME kdump kernel doesn't work without the
e820 reserved ranges. When SME is active in kdump kernel, actually, those
reserved regions are still decrypted, but because those reserved ranges are
not present at all in kdump kernel e820 table, those reserved regions are
considered as encrypted, it goes wrong.

The e820 reserved range is useful in kdump kernel, so it is necessary to
pass the e820 reserved ranges to the kdump kernel.

Suggested-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lianbo Jiang <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 17ffc869cab8..1db2754df9e9 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;
-- 
2.17.1


WARNING: multiple messages have this Message-ID (diff)
From: Lianbo Jiang <lijiang@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: Thomas.Lendacky@amd.com, x86@kernel.org, bhe@redhat.com,
	peterz@infradead.org, dave.hansen@linux.intel.com,
	kexec@lists.infradead.org, mingo@redhat.com, bp@alien8.de,
	luto@kernel.org, hpa@zytor.com, tglx@linutronix.de,
	dyoung@redhat.com, akpm@linux-foundation.org
Subject: [PATCH 3/3 v11] x86/kexec_file: add reserved e820 ranges to kdump kernel e820 table
Date: Tue, 23 Apr 2019 09:30:07 +0800	[thread overview]
Message-ID: <20190423013007.17838-4-lijiang@redhat.com> (raw)
In-Reply-To: <20190423013007.17838-1-lijiang@redhat.com>

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:

The first one is the MMCONFIG issue. The basic problem is that this
device is in PCI segment 1 and the kernel PCI probing can not find it
without all the e820 I/O reservations being present in the e820 table.
And 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. (This problem does not show up for other vendors, as SGI
is apparently the actually fails for everyone, but devices in segment 0
are then found by some legacy lookup method.) The workaround for this
is to pass the I/O reserved regions to the kdump kernel.

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 albe to access devices on
non-0 segments, (c) you won't be able to access extended config space(
address 0x100-0xffff), which means none of the Extended Capabilities will
be available(AER, ACS, ATS, etc). [Bjorn's comment]

The second issue is that the SME kdump kernel doesn't work without the
e820 reserved ranges. When SME is active in kdump kernel, actually, those
reserved regions are still decrypted, but because those reserved ranges are
not present at all in kdump kernel e820 table, those reserved regions are
considered as encrypted, it goes wrong.

The e820 reserved range is useful in kdump kernel, so it is necessary to
pass the e820 reserved ranges to the kdump kernel.

Suggested-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lianbo Jiang <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 17ffc869cab8..1db2754df9e9 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;
-- 
2.17.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  parent reply	other threads:[~2019-04-23  1:31 UTC|newest]

Thread overview: 47+ 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 ` 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-04-23  1:30   ` 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-04-23  1:30   ` 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 ` Lianbo Jiang [this message]
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:x86/kdump] x86/crash: Add e820 reserved ranges to kdump kernel's " tip-bot for Lianbo Jiang
2019-05-28  7:30 ` [PATCH 0/3 v11] add reserved e820 ranges to the kdump kernel " lijiang
2019-05-28  7:30   ` lijiang
2019-06-07 17:42   ` Borislav Petkov
2019-06-07 17:42     ` Borislav Petkov
2019-06-08  3:54     ` Baoquan He
2019-06-08  3:54       ` Baoquan He
2019-06-08  9:10       ` Borislav Petkov
2019-06-08  9:10         ` Borislav Petkov
2019-06-08 10:01         ` Baoquan He
2019-06-08 10:01           ` Baoquan He
2019-06-08 10:06           ` Borislav Petkov
2019-06-08 10:06             ` Borislav Petkov
2019-06-08 10:26             ` Baoquan He
2019-06-08 10:26               ` Baoquan He
2019-06-10 11:37               ` Borislav Petkov
2019-06-10 11:37                 ` Borislav Petkov
2019-06-12  1:14                 ` lijiang
2019-06-12  1:14                   ` lijiang
2019-06-12  1:55                 ` Baoquan He
2019-06-12  1:55                   ` Baoquan He
2019-06-12  5:49                   ` Dave Young
2019-06-12  5:49                     ` Dave Young
2019-06-12 15:10                   ` Borislav Petkov
2019-06-12 15:10                     ` Borislav Petkov
2019-06-12 16:52                     ` Lendacky, Thomas
2019-06-12 16:52                       ` Lendacky, Thomas
2019-06-12 18:07                       ` Borislav Petkov
2019-06-12 18:07                         ` Borislav Petkov
2019-06-12 19:10                         ` Lendacky, Thomas
2019-06-12 19:10                           ` Lendacky, Thomas
2019-06-13 15:07                           ` Baoquan He
2019-06-13 15:07                             ` Baoquan He
2019-06-13  1:18                         ` dyoung
2019-06-13  1:18                           ` dyoung
2019-06-09  4:02     ` lijiang
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=20190423013007.17838-4-lijiang@redhat.com \
    --to=lijiang@redhat.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dyoung@redhat.com \
    --cc=hpa@zytor.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.