[PATCH 0/2] x86/kexec_file: add reserved e820 ranges to the kdump kernel e820 table

[PATCH 0/2] x86/kexec_file: add reserved e820 ranges to the kdump kernel e820 table

[Lianbo Jiang]

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.

Furthermore, 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.

Kdump use walk_iomem_res_desc to iterate resources then add matched desc to
e820 table for the kdump kernel.

But IORES_DESC_NONE resource type includes several different e820 types, we
need add exact e820 type to the kdump kernel e820 table thus need an extra
checking in memmap_entry_callback to match the e820 type and resource name.

NOTE:
Before verifying this patches, you need to merge the following patch, which
uses to fix an upstream bug. For more information, you can refer to the link
below.
https://lore.kernel.org/patchwork/patch/986979/

Lianbo Jiang (2):
  x86/kexec_file: add e820 entry in case e820 type string matches to io
    resource name
  x86/kexec_file: add reserved e820 ranges to 2nd kernel e820 table

 arch/x86/include/asm/e820/api.h |  2 ++
 arch/x86/kernel/crash.c         | 12 +++++++++++-
 arch/x86/kernel/e820.c          |  2 +-
 kernel/resource.c               |  1 +
 4 files changed, 15 insertions(+), 2 deletions(-)

-- 
2.17.1

[PATCH 1/2] x86/kexec_file: add e820 entry in case e820 type string matches to io resource name

[Lianbo Jiang]

kdump use walk_iomem_res_desc to iterate io resources then add matched
desc to e820 table for 2nd kernel.

But IORES_DESC_NONE resource type includes several different e820 types,
we need add exact e820 type to 2nd kernel e820 table thus need an extra
checking in memmap_entry_callback to match the e820 type and resource
name.

Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
---
 arch/x86/include/asm/e820/api.h | 2 ++
 arch/x86/kernel/crash.c         | 6 +++++-
 arch/x86/kernel/e820.c          | 2 +-
 kernel/resource.c               | 1 +
 4 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/e820/api.h b/arch/x86/include/asm/e820/api.h
index 62be73b23d5c..f5e84fb9fe58 100644
--- a/arch/x86/include/asm/e820/api.h
+++ b/arch/x86/include/asm/e820/api.h
@@ -42,6 +42,8 @@ extern void e820__register_nosave_regions(unsigned long limit_pfn);
 
 extern int  e820__get_entry_type(u64 start, u64 end);
 
+extern const char* e820_type_to_string(struct e820_entry *entry);
+
 /*
  * Returns true iff the specified range [start,end) is completely contained inside
  * the ISA region.
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index f631a3f15587..3c113e6545a3 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -37,6 +37,7 @@
 #include <asm/reboot.h>
 #include <asm/virtext.h>
 #include <asm/intel_pt.h>
+#include <asm/e820/api.h>
 
 /* Used while preparing memory map entries for second kernel */
 struct crash_memmap_data {
@@ -314,11 +315,14 @@ static int memmap_entry_callback(struct resource *res, void *arg)
 	struct crash_memmap_data *cmd = arg;
 	struct boot_params *params = cmd->params;
 	struct e820_entry ei;
+	const char *name;
 
 	ei.addr = res->start;
 	ei.size = resource_size(res);
 	ei.type = cmd->type;
-	add_e820_entry(params, &ei);
+	name = e820_type_to_string(&ei);
+	if (!strcmp(name, res->name))
+		add_e820_entry(params, &ei);
 
 	return 0;
 }
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index c88c23c658c1..3e2fc4845fe7 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1012,7 +1012,7 @@ void __init e820__finish_early_params(void)
 	}
 }
 
-static const char *__init e820_type_to_string(struct e820_entry *entry)
+const char* e820_type_to_string(struct e820_entry *entry)
 {
 	switch (entry->type) {
 	case E820_TYPE_RESERVED_KERN:	/* Fall-through: */
diff --git a/kernel/resource.c b/kernel/resource.c
index f5d9fc70a04c..cc90633f35f9 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -366,6 +366,7 @@ static int find_next_iomem_res(struct resource *res, unsigned long desc,
 		res->end = p->end;
 	res->flags = p->flags;
 	res->desc = p->desc;
+	res->name = p->name;
 	return 0;
 }
 
-- 
2.17.1

[PATCH 2/2] x86/kexec_file: add reserved e820 ranges to 2nd kernel e820 table

[Lianbo Jiang]

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 <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 3c113e6545a3..db453e9c117b 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -384,6 +384,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 all reserved ranges */
+	cmd.type = E820_TYPE_RESERVED;
+	flags = IORESOURCE_MEM;
+	walk_iomem_res_desc(IORES_DESC_NONE, 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

Re: [PATCH 2/2] x86/kexec_file: add reserved e820 ranges to 2nd kernel e820 table

[Dave Young]

On 09/18/18 at 10:48am, Lianbo Jiang wrote:
> 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 <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 3c113e6545a3..db453e9c117b 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -384,6 +384,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 all reserved ranges */
> +	cmd.type = E820_TYPE_RESERVED;
> +	flags = IORESOURCE_MEM;

Lianbo, rethink about this, we will miss other io resource types if only
match IORESOURCE_MEM here, can you redo the patch with just using "0"
for the passing flags?

> +	walk_iomem_res_desc(IORES_DESC_NONE, 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
> 

Re: [PATCH 2/2] x86/kexec_file: add reserved e820 ranges to 2nd kernel e820 table

[lijiang]

在 2018年09月18日 11:20, Dave Young 写道:
> On 09/18/18 at 10:48am, Lianbo Jiang wrote:
>> 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 <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 3c113e6545a3..db453e9c117b 100644
>> --- a/arch/x86/kernel/crash.c
>> +++ b/arch/x86/kernel/crash.c
>> @@ -384,6 +384,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 all reserved ranges */
>> +	cmd.type = E820_TYPE_RESERVED;
>> +	flags = IORESOURCE_MEM;
> 
> Lianbo, rethink about this, we will miss other io resource types if only
> match IORESOURCE_MEM here, can you redo the patch with just using "0"
> for the passing flags?
> 

This patches align on kexec-tools for e820 reserved ranges, if so, the kexec-tools also need to
be improved for the other type, such as IORESOURCE_IO/BUS/DMA(...), right?

I will improve these patches and post v2 tomorrow.

Thanks.

>> +	walk_iomem_res_desc(IORES_DESC_NONE, 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
>>

Re: [PATCH 2/2] x86/kexec_file: add reserved e820 ranges to 2nd kernel e820 table

[Dave Young]

On 09/18/18 at 06:20pm, lijiang wrote:
> 在 2018年09月18日 11:20, Dave Young 写道:
> > On 09/18/18 at 10:48am, Lianbo Jiang wrote:
> >> 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 <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 3c113e6545a3..db453e9c117b 100644
> >> --- a/arch/x86/kernel/crash.c
> >> +++ b/arch/x86/kernel/crash.c
> >> @@ -384,6 +384,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 all reserved ranges */
> >> +	cmd.type = E820_TYPE_RESERVED;
> >> +	flags = IORESOURCE_MEM;
> > 
> > Lianbo, rethink about this, we will miss other io resource types if only
> > match IORESOURCE_MEM here, can you redo the patch with just using "0"
> > for the passing flags?
> > 
> 
> This patches align on kexec-tools for e820 reserved ranges, if so, the kexec-tools also need to
> be improved for the other type, such as IORESOURCE_IO/BUS/DMA(...), right?

Kexec-tools just go through /proc/iomem "reserved" items and add them
these flags are not visible to it.  So we have done same in kexec-tools.

> 
> I will improve these patches and post v2 tomorrow.

Thanks!
Dave