Re: [PATCH] kexec/kdump: Minor Documentation updates for arm64 and Image

2017-05-17 Thread Baoquan He 
On 05/18/17 at 11:03am, Bharat Bhushan wrote:
> This patch have minor updates in Documentation for arm64i as
> relocatable kernel.
> Also this patch updates documentation for using uncompressed
> image "Image" which is used for ARM64.
> 
> Signed-off-by: Bharat Bhushan 
> ---
>  Documentation/kdump/kdump.txt | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index 615434d..522ce13 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -112,8 +112,8 @@ There are two possible methods of using Kdump.
>  2) Or use the system kernel binary itself as dump-capture kernel and there is
> no need to build a separate dump-capture kernel. This is possible
> only with the architectures which support a relocatable kernel. As
> -   of today, i386, x86_64, ppc64, ia64 and arm architectures support 
> relocatable
> -   kernel.
> +   of today, i386, x86_64, ppc64, ia64, arm and arm64 architectures support
> +   relocatable kernel.
>  
>  Building a relocatable kernel is advantageous from the point of view that
>  one does not have to build a second kernel for capturing the dump. But
> @@ -361,6 +361,12 @@ to load dump-capture kernel.
> --dtb= \
> --append="root= "
>  
> +If you are using a uncompressed Image, then use following command
~ an
> +to load dump-capture kernel.
> +
> +   kexec -p  \
> +   --initrd= \
> +   --append="root= "
>  
>  Please note, that --args-linux does not need to be specified for ia64.
>  It is planned to make this a no-op on that architecture, but for now
> -- 
> 1.9.3
> 

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

[PATCH] kexec/kdump: Minor Documentation updates for arm64 and Image

2017-05-17 Thread Bharat Bhushan 
This patch have minor updates in Documentation for arm64i as
relocatable kernel.
Also this patch updates documentation for using uncompressed
image "Image" which is used for ARM64.

Signed-off-by: Bharat Bhushan 
---
 Documentation/kdump/kdump.txt | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 615434d..522ce13 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -112,8 +112,8 @@ There are two possible methods of using Kdump.
 2) Or use the system kernel binary itself as dump-capture kernel and there is
no need to build a separate dump-capture kernel. This is possible
only with the architectures which support a relocatable kernel. As
-   of today, i386, x86_64, ppc64, ia64 and arm architectures support 
relocatable
-   kernel.
+   of today, i386, x86_64, ppc64, ia64, arm and arm64 architectures support
+   relocatable kernel.
 
 Building a relocatable kernel is advantageous from the point of view that
 one does not have to build a second kernel for capturing the dump. But
@@ -361,6 +361,12 @@ to load dump-capture kernel.
--dtb= \
--append="root= "
 
+If you are using a uncompressed Image, then use following command
+to load dump-capture kernel.
+
+   kexec -p  \
+   --initrd= \
+   --append="root= "
 
 Please note, that --args-linux does not need to be specified for ia64.
 It is planned to make this a no-op on that architecture, but for now
-- 
1.9.3


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

RE: [PATCH] makedumpfile: Error on re-filtering the dump file with no free pages

2017-05-17 Thread Atsushi Kumagai 
Hello Zaslonko,

> When re-filtering the dump file after the free pages have already been
> stripped out we get an error "Can't get necessary symbols for excluding
> free pages" if newly specified dump level is below 16 (preserves free
> pages).
> According to the code, the check for the new dump level is done BEFORE
> the new dump level is actually set (based on the dump level specified in
> the command and the one from the input dump file).
> Moving the new_dump_level calculation ahead would fix the error.

Well, I guess the real problem is different.
The error you said is printed by exclude_free_page():

if ((SYMBOL(node_data) == NOT_FOUND_SYMBOL)
&& (SYMBOL(pgdat_list) == NOT_FOUND_SYMBOL)
&& (SYMBOL(contig_page_data) == NOT_FOUND_SYMBOL)) {
ERRMSG("Can't get necessary symbols for excluding free 
pages.\n");
return FALSE;
}

I think the availability of these symbols are not related to free pages.
exclude_free_page() is called if info->page_is_buddy is null, I estimate that
this situation occurs only if the kernel is older(2.6.16 or before). 

However, I don't think you use such too old kernel, so I suspect that
setup_page_is_buddy() should be updated for newer kernel.
Could you tell me your kernel version and how to reproduce this issue ?


Thanks,
Atsushi Kumagai

> Signed-off-by: Mikhail Zaslonko 
> ---
>  makedumpfile.c | 34 ++
>  1 file changed, 22 insertions(+), 12 deletions(-)
> 
> diff --git a/makedumpfile.c b/makedumpfile.c
> index e69b6df..24f99fc 100644
> --- a/makedumpfile.c
> +++ b/makedumpfile.c
> @@ -9774,10 +9774,25 @@ writeout_multiple_dumpfiles(void)
>   return ret;
>  }
> 
> +void
> +update_dump_level(void)
> +{
> + int new_level;
> +
> + new_level = info->dump_level | info->kh_memory->dump_level;
> + if (new_level != info->dump_level) {
> + info->dump_level = new_level;
> + MSG("dump_level is changed to %d, " \
> + "because %s was created by dump_level(%d).",
> + new_level, info->name_memory,
> + info->kh_memory->dump_level);
> + }
> +}
> +
>  int
>  create_dumpfile(void)
>  {
> - int num_retry, status, new_level;
> + int num_retry, status;
> 
>   if (!open_files_for_creating_dumpfile())
>   return FALSE;
> @@ -9786,6 +9801,10 @@ create_dumpfile(void)
>   if (!get_elf_info(info->fd_memory, info->name_memory))
>   return FALSE;
>   }
> +
> + if (info->flag_refiltering)
> + update_dump_level();
> +
>   if (!initial())
>   return FALSE;
> 
> @@ -9804,17 +9823,8 @@ create_dumpfile(void)
> 
>   num_retry = 0;
>  retry:
> - if (info->flag_refiltering) {
> - /* Change dump level */
> - new_level = info->dump_level | info->kh_memory->dump_level;
> - if (new_level != info->dump_level) {
> - info->dump_level = new_level;
> - MSG("dump_level is changed to %d, " \
> - "because %s was created by dump_level(%d).",
> - new_level, info->name_memory,
> - info->kh_memory->dump_level);
> - }
> - }
> + if (info->flag_refiltering)
> + update_dump_level();
> 
>   if ((info->name_filterconfig || info->name_eppic_config)
>   && !gather_filter_info())
> -- 
> 1.8.3.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v5 18/32] x86, mpparse: Use memremap to map the mpf and mpc data

2017-05-17 Thread Tom Lendacky 

On 5/16/2017 3:36 AM, Borislav Petkov wrote:

On Tue, Apr 18, 2017 at 04:19:30PM -0500, Tom Lendacky wrote:

The SMP MP-table is built by UEFI and placed in memory in a decrypted
state. These tables are accessed using a mix of early_memremap(),
early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses
to use early_memremap()/early_memunmap(). This allows for proper setting
of the encryption mask so that the data can be successfully accessed when
SME is active.

Signed-off-by: Tom Lendacky 
---
 arch/x86/kernel/mpparse.c |  102 +++--
 1 file changed, 71 insertions(+), 31 deletions(-)

diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c
index fd37f39..afbda41d 100644
--- a/arch/x86/kernel/mpparse.c
+++ b/arch/x86/kernel/mpparse.c
@@ -429,7 +429,21 @@ static inline void __init 
construct_default_ISA_mptable(int mpc_default_type)
}
 }

-static struct mpf_intel *mpf_found;
+static unsigned long mpf_base;
+
+static void __init unmap_mpf(struct mpf_intel *mpf)
+{
+   early_memunmap(mpf, sizeof(*mpf));
+}
+
+static struct mpf_intel * __init map_mpf(unsigned long paddr)
+{
+   struct mpf_intel *mpf;
+
+   mpf = early_memremap(paddr, sizeof(*mpf));
+
+   return mpf;


return early_memremap(paddr, sizeof(*mpf));



Ok.


...


@@ -842,25 +873,26 @@ static int __init update_mp_table(void)
if (!enable_update_mptable)
return 0;

-   mpf = mpf_found;
-   if (!mpf)
+   if (!mpf_base)
return 0;

+   mpf = map_mpf(mpf_base);
+
/*
 * Now see if we need to go further.
 */
if (mpf->feature1 != 0)


You're kidding, right? map_mpf() *can* return NULL.


Ugh...  don't know how I forgot about that. Will fix everywhere.



Also, simplify that test:

if (mpf->feature1)
...


Ok, I can do that but I hope no one says anything about it being
unrelated to the patch. :)





-   return 0;
+   goto do_unmap_mpf;

if (!mpf->physptr)
-   return 0;
+   goto do_unmap_mpf;

-   mpc = phys_to_virt(mpf->physptr);
+   mpc = map_mpc(mpf->physptr);


Again: error checking !!!

You have other calls to early_memremap()/map_mpf() in this patch. Please
add error checking everywhere.


Yup.





if (!smp_check_mpc(mpc, oem, str))
-   return 0;
+   goto do_unmap_mpc;

-   pr_info("mpf: %llx\n", (u64)virt_to_phys(mpf));
+   pr_info("mpf: %llx\n", (u64)mpf_base);
pr_info("physptr: %x\n", mpf->physptr);

if (mpc_new_phys && mpc->length > mpc_new_length) {
@@ -878,21 +910,23 @@ static int __init update_mp_table(void)
new = mpf_checksum((unsigned char *)mpc, mpc->length);
if (old == new) {
pr_info("mpc is readonly, please try alloc_mptable 
instead\n");
-   return 0;
+   goto do_unmap_mpc;
}
pr_info("use in-position replacing\n");
} else {
mpf->physptr = mpc_new_phys;
-   mpc_new = phys_to_virt(mpc_new_phys);
+   mpc_new = map_mpc(mpc_new_phys);


Ditto.


memcpy(mpc_new, mpc, mpc->length);
+   unmap_mpc(mpc);
mpc = mpc_new;
/* check if we can modify that */
if (mpc_new_phys - mpf->physptr) {
struct mpf_intel *mpf_new;
/* steal 16 bytes from [0, 1k) */
pr_info("mpf new: %x\n", 0x400 - 16);
-   mpf_new = phys_to_virt(0x400 - 16);
+   mpf_new = map_mpf(0x400 - 16);


Ditto.


memcpy(mpf_new, mpf, 16);
+   unmap_mpf(mpf);
mpf = mpf_new;
mpf->physptr = mpc_new_phys;
}




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

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

2017-05-17 Thread Borislav Petkov 
On Tue, Apr 18, 2017 at 04:21:21PM -0500, Tom Lendacky wrote:
> Provide support so that kexec can be used to boot a kernel when SME is
> enabled.
> 
> Support is needed to allocate pages for kexec without encryption.  This
> is needed in order to be able to reboot in the kernel in the same manner
> as originally booted.
> 
> Additionally, when shutting down all of the CPUs we need to be sure to
> flush the caches and then halt. This is needed when booting from a state
> where SME was not active into a state where SME is active (or vice-versa).
> Without these steps, it is possible for cache lines to exist for the same
> physical location but tagged both with and without the encryption bit. This
> can cause random memory corruption when caches are flushed depending on
> which cacheline is written last.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/init.h  |1 +
>  arch/x86/include/asm/irqflags.h  |5 +
>  arch/x86/include/asm/kexec.h |8 
>  arch/x86/include/asm/pgtable_types.h |1 +
>  arch/x86/kernel/machine_kexec_64.c   |   35 
> +-
>  arch/x86/kernel/process.c|   26 +++--
>  arch/x86/mm/ident_map.c  |   11 +++
>  include/linux/kexec.h|   14 ++
>  kernel/kexec_core.c  |7 +++
>  9 files changed, 101 insertions(+), 7 deletions(-)

...

> @@ -86,7 +86,7 @@ static int init_transition_pgtable(struct kimage *image, 
> pgd_t *pgd)
>   set_pmd(pmd, __pmd(__pa(pte) | _KERNPG_TABLE));
>   }
>   pte = pte_offset_kernel(pmd, vaddr);
> - set_pte(pte, pfn_pte(paddr >> PAGE_SHIFT, PAGE_KERNEL_EXEC));
> + set_pte(pte, pfn_pte(paddr >> PAGE_SHIFT, PAGE_KERNEL_EXEC_NOENC));
>   return 0;
>  err:
>   free_transition_pgtable(image);
> @@ -114,6 +114,7 @@ static int init_pgtable(struct kimage *image, unsigned 
> long start_pgtable)
>   .alloc_pgt_page = alloc_pgt_page,
>   .context= image,
>   .pmd_flag   = __PAGE_KERNEL_LARGE_EXEC,
> + .kernpg_flag= _KERNPG_TABLE_NOENC,
>   };
>   unsigned long mstart, mend;
>   pgd_t *level4p;
> @@ -597,3 +598,35 @@ void arch_kexec_unprotect_crashkres(void)
>  {
>   kexec_mark_crashkres(false);
>  }
> +
> +int arch_kexec_post_alloc_pages(void *vaddr, unsigned int pages, gfp_t gfp)
> +{
> + int ret;
> +
> + if (sme_active()) {

if (!sme_active())
return 0;

/*
 * If SME...


> + /*
> +  * If SME is active we need to be sure that kexec pages are
> +  * not encrypted because when we boot to the new kernel the
> +  * pages won't be accessed encrypted (initially).
> +  */
> + ret = set_memory_decrypted((unsigned long)vaddr, pages);
> + if (ret)
> + return ret;
> +
> + if (gfp & __GFP_ZERO)
> + memset(vaddr, 0, pages * PAGE_SIZE);

This function is called after alloc_pages() which already zeroes memory
when __GFP_ZERO is supplied.

If you need to clear the memory *after* set_memory_encrypted() happens,
then you should probably mask out __GFP_ZERO before the alloc_pages()
call so as not to do it twice.

> + }
> +
> + return 0;
> +}
> +
> +void arch_kexec_pre_free_pages(void *vaddr, unsigned int pages)
> +{
> + if (sme_active()) {
> + /*
> +  * If SME is active we need to reset the pages back to being
> +  * an encrypted mapping before freeing them.
> +  */
> + set_memory_encrypted((unsigned long)vaddr, pages);
> + }
> +}
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index 0bb8842..f4e5de6 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -355,8 +356,25 @@ bool xen_set_default_idle(void)
>   return ret;
>  }
>  #endif
> +
>  void stop_this_cpu(void *dummy)
>  {
> + bool do_wbinvd_halt = false;
> +
> + if (kexec_in_progress && boot_cpu_has(X86_FEATURE_SME)) {
> + /*
> +  * If we are performing a kexec and the processor supports
> +  * SME then we need to clear out cache information before
> +  * halting. With kexec, going from SME inactive to SME active
> +  * requires clearing cache entries so that addresses without
> +  * the encryption bit set don't corrupt the same physical
> +  * address that has the encryption bit set when caches are
> +  * flushed. Perform a wbinvd followed by a halt to achieve
> +  * this.
> +  */
> + do_wbinvd_halt = true;
> + }
> +
>   local_irq_disable();
>   /*
>

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

2017-05-17 Thread Tom Lendacky 

On 5/15/2017 1:35 PM, Borislav Petkov wrote:

On Tue, Apr 18, 2017 at 04:19:21PM -0500, Tom Lendacky wrote:

Boot data (such as EFI related data) is not encrypted when the system is
booted because UEFI/BIOS does not run with SME active. In order to access
this data properly it needs to be mapped decrypted.

The early_memremap() support is updated to provide an arch specific


"Update early_memremap() to provide... "


Will do.




routine to modify the pagetable protection attributes before they are
applied to the new mapping. This is used to remove the encryption mask
for boot related data.

The memremap() support is updated to provide an arch specific routine


Ditto. Passive tone always reads harder than an active tone,
"doer"-sentence.


Ditto.




to determine if RAM remapping is allowed.  RAM remapping will cause an
encrypted mapping to be generated. By preventing RAM remapping,
ioremap_cache() will be used instead, which will provide a decrypted
mapping of the boot related data.

Signed-off-by: Tom Lendacky 
---
 arch/x86/include/asm/io.h |4 +
 arch/x86/mm/ioremap.c |  182 +
 include/linux/io.h|2
 kernel/memremap.c |   20 -
 mm/early_ioremap.c|   18 
 5 files changed, 219 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 7afb0e2..75f2858 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -381,4 +381,8 @@ extern int __must_check arch_phys_wc_add(unsigned long base,
 #define arch_io_reserve_memtype_wc arch_io_reserve_memtype_wc
 #endif

+extern bool arch_memremap_do_ram_remap(resource_size_t offset, size_t size,
+  unsigned long flags);
+#define arch_memremap_do_ram_remap arch_memremap_do_ram_remap
+
 #endif /* _ASM_X86_IO_H */
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 9bfcb1f..bce0604 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -21,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "physaddr.h"

@@ -419,6 +421,186 @@ void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
iounmap((void __iomem *)((unsigned long)addr & PAGE_MASK));
 }

+/*
+ * Examine the physical address to determine if it is an area of memory
+ * that should be mapped decrypted.  If the memory is not part of the
+ * kernel usable area it was accessed and created decrypted, so these
+ * areas should be mapped decrypted.
+ */
+static bool memremap_should_map_decrypted(resource_size_t phys_addr,
+ unsigned long size)
+{
+   /* Check if the address is outside kernel usable area */
+   switch (e820__get_entry_type(phys_addr, phys_addr + size - 1)) {
+   case E820_TYPE_RESERVED:
+   case E820_TYPE_ACPI:
+   case E820_TYPE_NVS:
+   case E820_TYPE_UNUSABLE:
+   return true;
+   default:
+   break;
+   }
+
+   return false;
+}
+
+/*
+ * Examine the physical address to determine if it is EFI data. Check
+ * it against the boot params structure and EFI tables and memory types.
+ */
+static bool memremap_is_efi_data(resource_size_t phys_addr,
+unsigned long size)
+{
+   u64 paddr;
+
+   /* Check if the address is part of EFI boot/runtime data */
+   if (efi_enabled(EFI_BOOT)) {


Save indentation level:

if (!efi_enabled(EFI_BOOT))
return false;



I was worried what the compiler might do when CONFIG_EFI is not set,
but it appears to take care of it. I'll double check though.




+   paddr = boot_params.efi_info.efi_memmap_hi;
+   paddr <<= 32;
+   paddr |= boot_params.efi_info.efi_memmap;
+   if (phys_addr == paddr)
+   return true;
+
+   paddr = boot_params.efi_info.efi_systab_hi;
+   paddr <<= 32;
+   paddr |= boot_params.efi_info.efi_systab;


So those two above look like could be two global vars which are
initialized somewhere in the EFI init path:

efi_memmap_phys and efi_systab_phys or so.

Matt ?

And then you won't need to create that paddr each time on the fly. I
mean, it's not a lot of instructions but still...


+   if (phys_addr == paddr)
+   return true;
+
+   if (efi_table_address_match(phys_addr))
+   return true;
+
+   switch (efi_mem_type(phys_addr)) {
+   case EFI_BOOT_SERVICES_DATA:
+   case EFI_RUNTIME_SERVICES_DATA:
+   return true;
+   default:
+   break;
+   }
+   }
+
+   return false;
+}
+
+/*
+ * Examine the physical address to determine if it is boot data by checking
+ * it against the boot params setup_data

[PATCH] makedumpfile: Error on re-filtering the dump file with no free pages

2017-05-17 Thread Zaslonko Mikhail 

Please find the enclosed patch below.

From 627b4c8085269251f6d66627dada447909bceafd Mon Sep 17 00:00:00 2001
From: root 
Date: Tue, 16 May 2017 14:08:14 +0200
Subject: [PATCH] makedumpfile: Error on re-filtering the dump file with no
 free pages

When re-filtering the dump file after the free pages have already been
stripped out we get an error "Can't get necessary symbols for excluding
free pages" if newly specified dump level is below 16 (preserves free
pages).
According to the code, the check for the new dump level is done BEFORE
the new dump level is actually set (based on the dump level specified in
the command and the one from the input dump file).
Moving the new_dump_level calculation ahead would fix the error.

Signed-off-by: Mikhail Zaslonko 
---
 makedumpfile.c | 34 ++
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/makedumpfile.c b/makedumpfile.c
index e69b6df..24f99fc 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -9774,10 +9774,25 @@ writeout_multiple_dumpfiles(void)
return ret;
 }

+void
+update_dump_level(void)
+{
+   int new_level;
+
+   new_level = info->dump_level | info->kh_memory->dump_level;
+   if (new_level != info->dump_level) {
+   info->dump_level = new_level;
+   MSG("dump_level is changed to %d, " \
+   "because %s was created by dump_level(%d).",
+   new_level, info->name_memory,
+   info->kh_memory->dump_level);
+   }
+}
+
 int
 create_dumpfile(void)
 {
-   int num_retry, status, new_level;
+   int num_retry, status;

if (!open_files_for_creating_dumpfile())
return FALSE;
@@ -9786,6 +9801,10 @@ create_dumpfile(void)
if (!get_elf_info(info->fd_memory, info->name_memory))
return FALSE;
}
+
+   if (info->flag_refiltering)
+   update_dump_level();
+
if (!initial())
return FALSE;

@@ -9804,17 +9823,8 @@ create_dumpfile(void)

num_retry = 0;
 retry:
-   if (info->flag_refiltering) {
-   /* Change dump level */
-   new_level = info->dump_level | info->kh_memory->dump_level;
-   if (new_level != info->dump_level) {
-   info->dump_level = new_level;
-   MSG("dump_level is changed to %d, " \
-   "because %s was created by dump_level(%d).",
-   new_level, info->name_memory,
-   info->kh_memory->dump_level);
-   }
-   }
+   if (info->flag_refiltering)
+   update_dump_level();

if ((info->name_filterconfig || info->name_eppic_config)
&& !gather_filter_info())
-- 
1.8.3.1

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

Re: [PATCH] Handle additional e820 memmap type strings

2017-05-17 Thread Eric DeVolder 



On 05/15/2017 09:07 AM, Baoquan He wrote:

On 05/10/17 at 11:03am, Eric DeVolder wrote:

Keep pace with changes to linux arch/x86/kernel/e820.c to
function e820_type_to_string(). With this change, the following
messages from kexec are eliminated (and allows kexec to load):

  Unknown type (Reserved) while parsing /sys/firmware/memmap/8/type.
  Please report this as bug. Using RANGE_RESERVED now.

  Unknown type (Unknown E820 type) while parsing /sys/firmware/memmap/4/type.
  Please report this as bug. Using RANGE_RESERVED now.

Signed-off-by: Eric DeVolder 
---
  kexec/firmware_memmap.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/kexec/firmware_memmap.c b/kexec/firmware_memmap.c
index 4d84f00..1ee214a 100644
--- a/kexec/firmware_memmap.c
+++ b/kexec/firmware_memmap.c
@@ -164,6 +164,10 @@ static int parse_memmap_entry(const char *entry, struct 
memory_range *range)
range->type = RANGE_RESERVED;
else if (strcmp(type, "reserved") == 0)
range->type = RANGE_RESERVED;
+   else if (strcmp(type, "Reserved") == 0)
+   range->type = RANGE_RESERVED;
+   else if (strcmp(type, "Unknown E820 type") == 0)
+   range->type = RANGE_RESERVED;


Should we change the "reserved" one to "Reserved" so that we don't need
to have "reserved" and "Reserved" at the same time?


The lower-case "reserved" has been in use by the kernel for quite a long 
while, and upper-case "Reserved" has been recently introduced. I think 
removing lower-case "reserved" would result in problems with existing, 
older, kernels that still would be using "reserved".





else if (strcmp(type, "ACPI Non-volatile Storage") == 0)
range->type = RANGE_ACPI_NVS;
else if (strcmp(type, "Uncached RAM") == 0)
--
2.7.4


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


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

RE: [Makedumpfile PATCH V3] elf_info: fix file_size if segment is excluded

2017-05-17 Thread Atsushi Kumagai 
Hello Pratyush,

Sorry for late reply.
I have no further comment for now, but the current --mem-usage
seems have some problems. I can't decide that this patch is insufficient or
that's quite a different matter now, so please let me defer acknowledgment
for a while.

Thanks,
Atsushi Kumagai

>I received following on a specific x86_64 hp virtual machine while
>executing `makedumpfile --mem-usage /proc/kcore`.
>
>vtop4_x86_64: Can't get a valid pte.
>readmem: Can't convert a virtual address(88115860) to physical address.
>readmem: type_addr: 0, addr:88115860, size:128
>get_nodes_online: Can't get the node online map.
>
>With some debug print in vtop4_x86_64() I noticed that pte value is read
>as 0, while crash reads the value correctly:
>
>from makedumpfile:
>vaddr=88115860
>page_dir=59eaff8
>pml4=59ed067
>pgd_paddr=59edff0
>pgd_pte=59ee063
>pmd_paddr=59ee200
>pmd_pte=3642f063
>pte_paddr=3642f8a8
>pte=0
>
>from crash
>crash> vtop 88115860
>VIRTUAL   PHYSICAL
>88115860  5b15860
>
>PML4 DIRECTORY: 87fea000
>PAGE DIRECTORY: 59ed067
>   PUD: 59edff0 => 59ee063
>   PMD: 59ee200 => 3642f063
>   PTE: 3642f8a8 => 5b15163
>  PAGE: 5b15000
>
>With some more debug prints in elf_info.c
>
>Before calling exclude_segment()
>
>LOAD (2)
>  phys_start : 10
>  phys_end   : dfffd000
>  virt_start : 8a5a4010
>  virt_end   : 8a5b1fffd000
>  file_offset: a5a40102000
>  file_size  : dfefd000
>
>exclude_segment() is called for Crash Kernel whose range is
>2b00-350f.
>
>We see following after exclude_segment()
>
>LOAD (2)
>  phys_start : 10
>  phys_end   : 2aff
>  virt_start : 8a5a4010
>  virt_end   : 8a5a6aff
>  file_offset: a5a40102000
>  file_size  : dfefd000
>LOAD (3)
>  phys_start : 3510
>  phys_end   : dfffd000
>  virt_start : 8a5a7510
>  virt_end   : 8a5b1fffd000
>  file_offset: a5a75102000
>  file_size  : 0
>
>Since file_size is calculated wrong therefore readpage_elf() does not
>behave correctly.
>
>This patch fixes above wrong behavior.
>
>Signed-off-by: Pratyush Anand 
>---
>v1->v2 : subtracted (end - start) from file_size as well
>v2->v3 : subtracted (end - start) for boundary cases as well.
> elf_info.c | 4 
> 1 file changed, 4 insertions(+)
>
>diff --git a/elf_info.c b/elf_info.c
>index 8e2437622141..2c58359a438f 100644
>--- a/elf_info.c
>+++ b/elf_info.c
>@@ -826,9 +826,12 @@ static int exclude_segment(struct pt_load_segment 
>**pt_loads,
>   temp_seg.virt_end = vend;
>   temp_seg.file_offset = 
> (*pt_loads)[i].file_offset
>   + temp_seg.virt_start - 
> (*pt_loads)[i].virt_start;
>+  temp_seg.file_size = temp_seg.phys_end
>+  - temp_seg.phys_start;
>
>   (*pt_loads)[i].virt_end = kvstart - 1;
>   (*pt_loads)[i].phys_end =  start - 1;
>+  (*pt_loads)[i].file_size -= temp_seg.file_size;
>
>   tidx = i+1;
>   } else if (kvstart != vstart) {
>@@ -838,6 +841,7 @@ static int exclude_segment(struct pt_load_segment 
>**pt_loads,
>   (*pt_loads)[i].phys_start = end + 1;
>   (*pt_loads)[i].virt_start = kvend + 1;
>   }
>+  (*pt_loads)[i].file_size -= (end -start);
>   }
>   }
>   /* Insert split load segment, if any. */
>--
>2.9.3
>



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

Re: [PATCH v5 06/32] x86/mm: Add Secure Memory Encryption (SME) support

2017-05-17 Thread Borislav Petkov 
On Tue, May 16, 2017 at 02:28:42PM -0500, Tom Lendacky wrote:
> It's most problematic when CONFIG_AMD_MEM_ENCRYPT is not defined since
> we never include an asm/ version from the linux/ path.  I could create
> a mem_encrypt.h in include/asm-generic/ that contains the info that
> is in the !CONFIG_AMD_MEM_ENCRYPT path of the linux/ version. Let me
> look into that.

So we need to keep asm/ and linux/ apart. The linux/ stuff is generic,
global, more or less. The asm/ is arch-specific. So they shouldn't be
overlapping wrt definitions, IMHO.

So asm-generic is the proper approach here because then you won't need
the ifndef fun.

Thanks.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

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