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
next prev 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: linkBe 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.