Re: [Resend][Patch v2] kexec: increase max of kexec segments and use dynamic allocation
On Fri, Aug 13, 2010 at 01:38:54AM -0400, Amerigo Wang wrote:
Currently KEXEC_SEGMENT_MAX is only 16 which is too small for machine with
many memory ranges. When hibernate on a machine with disjoint memory we do
need one segment for each memory region. Increase this hard limit to 16K
which is reasonably large.
And change -segment from a static array to a dynamically allocated memory.
FWIW, this looks good to me.
Reviewed-by: Simon Horman ho...@verge.net.au
Cc: Neil Horman nhor...@redhat.com
Cc: Vivek Goyal vgo...@redhat.com
Cc: huang ying huang.ying.cari...@gmail.com
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Signed-off-by: WANG Cong amw...@redhat.com
---
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index 583af70..93f0542 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -134,10 +134,7 @@ static void copy_segments(unsigned long ind)
void kexec_copy_flush(struct kimage *image)
{
long i, nr_segments = image-nr_segments;
- struct kexec_segment ranges[KEXEC_SEGMENT_MAX];
-
- /* save the ranges on the stack to efficiently flush the icache */
- memcpy(ranges, image-segment, sizeof(ranges));
+ struct kexec_segment range;
/*
* After this call we may not use anything allocated in dynamic
@@ -151,9 +148,11 @@ void kexec_copy_flush(struct kimage *image)
* we need to clear the icache for all dest pages sometime,
* including ones that were in place on the original copy
*/
- for (i = 0; i nr_segments; i++)
- flush_icache_range((unsigned long)__va(ranges[i].mem),
- (unsigned long)__va(ranges[i].mem + ranges[i].memsz));
+ for (i = 0; i nr_segments; i++) {
+ memcpy(range, image-segment[i], sizeof(range));
+ flush_icache_range((unsigned long)__va(range.mem),
+ (unsigned long)__va(range.mem + range.memsz));
+ }
}
#ifdef CONFIG_SMP
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 03e8e8d..ec783c1 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -57,7 +57,7 @@ typedef unsigned long kimage_entry_t;
#define IND_DONE 0x4
#define IND_SOURCE 0x8
-#define KEXEC_SEGMENT_MAX 16
+#define KEXEC_SEGMENT_MAX (1024*16)
struct kexec_segment {
void __user *buf;
size_t bufsz;
@@ -86,7 +86,7 @@ struct kimage {
struct page *swap_page;
unsigned long nr_segments;
- struct kexec_segment segment[KEXEC_SEGMENT_MAX];
+ struct kexec_segment *segment;
struct list_head control_pages;
struct list_head dest_pages;
diff --git a/kernel/kexec.c b/kernel/kexec.c
index c0613f7..22ff794 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -131,6 +131,11 @@ static int do_kimage_alloc(struct kimage **rimage,
unsigned long entry,
if (!image)
goto out;
+ image-segment = kzalloc(nr_segments * sizeof(struct kexec_segment),
+ GFP_KERNEL);
+ if (!image-segment)
+ goto out;
+
image-head = 0;
image-entry = image-head;
image-last_entry = image-head;
@@ -218,8 +223,10 @@ static int do_kimage_alloc(struct kimage **rimage,
unsigned long entry,
out:
if (result == 0)
*rimage = image;
- else
+ else if (image) {
+ kfree(image-segment);
kfree(image);
+ }
return result;
@@ -263,8 +270,10 @@ static int kimage_normal_alloc(struct kimage **rimage,
unsigned long entry,
out:
if (result == 0)
*rimage = image;
- else
+ else if (image) {
+ kfree(image-segment);
kfree(image);
+ }
return result;
}
@@ -332,8 +341,10 @@ static int kimage_crash_alloc(struct kimage **rimage,
unsigned long entry,
out:
if (result == 0)
*rimage = image;
- else
+ else if (image) {
+ kfree(image-segment);
kfree(image);
+ }
return result;
}
@@ -658,6 +669,7 @@ static void kimage_free(struct kimage *image)
/* Free the kexec control pages... */
kimage_free_page_list(image-control_pages);
+ kfree(image-segment);
kfree(image);
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [Resend][Patch v2] kexec: increase max of kexec segments and use dynamic allocation
On Fri, Aug 13, 2010 at 01:38:54AM -0400, Amerigo Wang wrote: Currently KEXEC_SEGMENT_MAX is only 16 which is too small for machine with many memory ranges. When hibernate on a machine with disjoint memory we do need one segment for each memory region. Increase this hard limit to 16K which is reasonably large. And change -segment from a static array to a dynamically allocated memory. Cc: Neil Horman nhor...@redhat.com Cc: Vivek Goyal vgo...@redhat.com Cc: huang ying huang.ying.cari...@gmail.com Cc: Eric W. Biederman ebied...@xmission.com Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Signed-off-by: WANG Cong amw...@redhat.com Concur with Simon Reviewed-by: Neil Horman nhor...@tuxdriver.com ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH][EFI] Run EFI in physical mode
Hi all,
The attached patch enables EFI to run in physical mode.
Basically EFI is in physical mode at first and it's switched to virtual
mode after calling SetVirtualAddressMap. By applying this patch, you can
run EFI always in physical mode. And you can also specify virtefi as
kernel boot parameter to run EFI in virtual mode as before. Note that
this patch supports only x86_64.
This is needed to run kexec/kdump in EFI-booted system. The following is
an original discussion. In this thread, I explained that kdump does not
work because EFI system table is modified by SetVirtualAddressMap. And
the idea to run EFI in physical mode was proposed. This patch implements
it.
http://marc.info/?l=linux-kernelm=128018221820234w=2
When the 1st kernel boots, EFI system table(efi_system_table_t) is
modified by SetVirtualAddressMap, which is one of EFI runtime service.
This runtime changes physical address in EFI system table to virtual
address.
When the 2nd kernel boots, it also receives the same EFI system table,
and the address included in it is already virtual address(1st kernel
rewrote it). But 2nd kernel does not know that, 2nd kernel thinks it is
a physical address. This causes problems.
Basic idea of this patch is to create EFI own pagetable. This pagetable
maps physical address of EFI runtime to the virtual address which is the
same value so that we can call it directly. For example, physical
address 0x80 is mapped to virtual address 0x80. Before calling
EFI runtime, cr3 register is switched to this pagetable, and restored
when we come back from EFI.
Any comments would be appreciated.
Signed-off-by: Takao Indoh indou.ta...@jp.fujitsu.com
---
arch/x86/include/asm/efi.h |3
arch/x86/kernel/efi.c | 142 ++-
arch/x86/kernel/efi_32.c |4
arch/x86/kernel/efi_64.c | 92 ++
include/linux/efi.h|1
include/linux/init.h |1
init/main.c| 16 +++
7 files changed, 254 insertions(+), 5 deletions(-)
diff -Nurp linux-2.6.35.org/arch/x86/include/asm/efi.h
linux-2.6.35/arch/x86/include/asm/efi.h
--- linux-2.6.35.org/arch/x86/include/asm/efi.h 2010-08-01 18:11:14.0
-0400
+++ linux-2.6.35/arch/x86/include/asm/efi.h 2010-08-13 14:39:25.817104994
-0400
@@ -93,6 +93,9 @@ extern int add_efi_memmap;
extern void efi_reserve_early(void);
extern void efi_call_phys_prelog(void);
extern void efi_call_phys_epilog(void);
+extern void efi_call_phys_prelog_in_physmode(void);
+extern void efi_call_phys_epilog_in_physmode(void);
+extern void efi_pagetable_init(void);
#ifndef CONFIG_EFI
/*
diff -Nurp linux-2.6.35.org/arch/x86/kernel/efi.c
linux-2.6.35/arch/x86/kernel/efi.c
--- linux-2.6.35.org/arch/x86/kernel/efi.c 2010-08-01 18:11:14.0
-0400
+++ linux-2.6.35/arch/x86/kernel/efi.c 2010-08-13 14:39:25.819105004 -0400
@@ -57,6 +57,7 @@ struct efi_memory_map memmap;
static struct efi efi_phys __initdata;
static efi_system_table_t efi_systab __initdata;
+static efi_runtime_services_t phys_runtime;
static int __init setup_noefi(char *arg)
{
@@ -171,7 +172,7 @@ static efi_status_t __init phys_efi_set_
return status;
}
-static efi_status_t __init phys_efi_get_time(efi_time_t *tm,
+static efi_status_t __init phys_efi_get_time_early(efi_time_t *tm,
efi_time_cap_t *tc)
{
efi_status_t status;
@@ -182,6 +183,112 @@ static efi_status_t __init phys_efi_get_
return status;
}
+static efi_status_t phys_efi_get_time(efi_time_t *tm,
+ efi_time_cap_t *tc)
+{
+ efi_status_t status;
+
+ efi_call_phys_prelog_in_physmode();
+ status = efi_call_phys2((void*)phys_runtime.get_time, tm, tc);
+ efi_call_phys_epilog_in_physmode();
+ return status;
+}
+
+static efi_status_t __init phys_efi_set_time(efi_time_t *tm)
+{
+ efi_status_t status;
+
+ efi_call_phys_prelog_in_physmode();
+ status = efi_call_phys1((void*)phys_runtime.set_time, tm);
+ efi_call_phys_epilog_in_physmode();
+ return status;
+}
+
+static efi_status_t phys_efi_get_wakeup_time(efi_bool_t *enabled,
+ efi_bool_t *pending,
+ efi_time_t *tm)
+{
+ efi_status_t status;
+
+ efi_call_phys_prelog_in_physmode();
+ status = efi_call_phys3((void*)phys_runtime.get_wakeup_time, enabled,
+ pending, tm);
+ efi_call_phys_epilog_in_physmode();
+ return status;
+}
+
+static efi_status_t phys_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t
*tm)
+{
+ efi_status_t status;
+ efi_call_phys_prelog_in_physmode();
+ status = efi_call_phys2((void*)phys_runtime.set_wakeup_time, enabled,
+ tm);
+ efi_call_phys_epilog_in_physmode();
+ return status;
+}
+
+static efi_status_t
Re: [PATCH][EFI] Run EFI in physical mode
Takao Indoh indou.ta...@jp.fujitsu.com writes: Hi all, The attached patch enables EFI to run in physical mode. Basically EFI is in physical mode at first and it's switched to virtual mode after calling SetVirtualAddressMap. By applying this patch, you can run EFI always in physical mode. And you can also specify virtefi as kernel boot parameter to run EFI in virtual mode as before. Note that this patch supports only x86_64. This is needed to run kexec/kdump in EFI-booted system. The following is an original discussion. In this thread, I explained that kdump does not work because EFI system table is modified by SetVirtualAddressMap. And the idea to run EFI in physical mode was proposed. This patch implements it. http://marc.info/?l=linux-kernelm=128018221820234w=2 When the 1st kernel boots, EFI system table(efi_system_table_t) is modified by SetVirtualAddressMap, which is one of EFI runtime service. This runtime changes physical address in EFI system table to virtual address. When the 2nd kernel boots, it also receives the same EFI system table, and the address included in it is already virtual address(1st kernel rewrote it). But 2nd kernel does not know that, 2nd kernel thinks it is a physical address. This causes problems. Basic idea of this patch is to create EFI own pagetable. This pagetable maps physical address of EFI runtime to the virtual address which is the same value so that we can call it directly. For example, physical address 0x80 is mapped to virtual address 0x80. Before calling EFI runtime, cr3 register is switched to this pagetable, and restored when we come back from EFI. Any comments would be appreciated. Signed-off-by: Takao Indoh indou.ta...@jp.fujitsu.com Acked-by: Eric W. Biederman ebied...@xmission.com There is what appears to be unneeded redundancy (we need two implementations of physciall calls into efi?), but that is confined to the weird efi state. It is a shame you haven't done the little bit extra to get efi_pagetable_init working on x86_32. Overall this seems sane and confined to the x86 efi, and it looks like further improvements could easily be layered on top of this one. Eric ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH][EFI] Run EFI in physical mode
On 08/13/2010 12:18 PM, Takao Indoh wrote: Basically EFI is in physical mode at first and it's switched to virtual mode after calling SetVirtualAddressMap. By applying this patch, you can run EFI always in physical mode. And you can also specify virtefi as kernel boot parameter to run EFI in virtual mode as before. Note that this patch supports only x86_64. Any hope to get a followon patch for i386 as well? That would make it largely a no-brainer. Tony, does this affect ia64 in any way? -hpa ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH][EFI] Run EFI in physical mode
On 08/13/2010 12:18 PM, Takao Indoh wrote: Hi all, The attached patch enables EFI to run in physical mode. Basically EFI is in physical mode at first and it's switched to virtual mode after calling SetVirtualAddressMap. By applying this patch, you can run EFI always in physical mode. And you can also specify virtefi as kernel boot parameter to run EFI in virtual mode as before. Note that this patch supports only x86_64. This is needed to run kexec/kdump in EFI-booted system. The following is an original discussion. In this thread, I explained that kdump does not work because EFI system table is modified by SetVirtualAddressMap. And the idea to run EFI in physical mode was proposed. This patch implements it. http://marc.info/?l=linux-kernelm=128018221820234w=2 When the 1st kernel boots, EFI system table(efi_system_table_t) is modified by SetVirtualAddressMap, which is one of EFI runtime service. This runtime changes physical address in EFI system table to virtual address. When the 2nd kernel boots, it also receives the same EFI system table, and the address included in it is already virtual address(1st kernel rewrote it). But 2nd kernel does not know that, 2nd kernel thinks it is a physical address. This causes problems. Basic idea of this patch is to create EFI own pagetable. This pagetable maps physical address of EFI runtime to the virtual address which is the same value so that we can call it directly. For example, physical address 0x80 is mapped to virtual address 0x80. Before calling EFI runtime, cr3 register is switched to this pagetable, and restored when we come back from EFI. Any comments would be appreciated. Another aspect of this... this plays well into the already-outstanding proposal to keep an identity-mapped set of page tables around at all times. Right now we do it ad hoc for 64 bits and not really for 32 bits, but that is being changed, see the thread starting at: http://marc.info/?i=1280940316-7966-1-git-send-email...@amd64.org This would definitely be better than keeping yet another private page table. -hpa ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
RE: [PATCH][EFI] Run EFI in physical mode
does this affect ia64 in any way? I remember Eric complaining that set_virtual_address_map() was a one way trap door with no way to get back to physical mode ... and thus this was a big problem to support kexec on ia64. And yet we still call it, and ia64 can do kexec. So some other work around must have been found. Can't immediately remember what it was though. -Tony ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
INTERNATIONAL SYMPOSIUM INVITATION !!!!!!!!!!!!!!!!
Dear friend, It is my pleasure to pass you this grate invitation on behalf of Global Right Organization here in United State of America, I am Miss. Alberta Smith, a member and staff of global right red cross committee. I wish to extend an invitation to you in participating with us in this grate International Seminal on Human Protection and Violence, which the Global Right Organization (GRO) is hosting on September 27th to 1st of October 2010 at 637 Place 14th Street, NW Washington, DC 10111 United States Of America, and from October 4th to 8th of October 2010 at Rue 47 Vlu Ba Maline Ave Dakar, Senegal West Africa. In our request to invite people from various countries around the world, we went in search of professionals and NGO members on the Google search as a means of contacting people and organizations. As a result, your email address was picked, if you are interested to participate as an individual or would like to represent your country or organization; you may contact the Seminal secretariat for more details and information regarding registration for the workshop Attendees of the up coming international symposium include; directors, doctors, professors, teachers, and other professionals from various department and staff, including students, managers and others against Violence and how we can stop Violence from developing in our world, society, homes and individuals lives. The seminal will be addressed by prominent speakers of the humanitarian industry who will engage through their interactive session to bring forth relevant issues. After you have been fully registered for the international seminal, you will be provided with air round trip tickets, accommodation here in United State and visa processing to participate in both phase of the seminal. Note that you will only have to pay and be responsible for your reservation in West Africa where the second phase of the seminal will be held. If you are a holder of passport that may require visa to enter into the U.S, you may inform the secretariat when sending your passport information's for registration, as the organizing committee is responsible for all visa arrangements. I encourage you to share this invitation with anyone you believe would be interested in attending the seminal. You can contact the secretariat: (Mrs. Katherine Wage) van email: secretary...@aol.com for additional information on registration, if you need any assistant you can write me on my email: alberta.c.sm...@globomail.com Yours Sincerely, Miss. Alberta Smith. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH][EFI] Run EFI in physical mode
On 08/13/2010 04:11 PM, Eric W. Biederman wrote: As to Peter's question I did not see any of that code that affected anything that ia64 used. I guess my real question was is this something IA64 could benefit from and/or could we make the IA64 code more similar to the x86 bits? -hpa ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH][EFI] Run EFI in physical mode
On Fri, Aug 13, 2010 at 4:16 PM, H. Peter Anvin h...@zytor.com wrote: I guess my real question was is this something IA64 could benefit from and/or could we make the IA64 code more similar to the x86 bits? If Eric's recollection about the weird floating point fixup routines[1] performance issues are correct - then ia64 won't want to do this. -Tony [1] more usually called FPSWA - floating point software assist - which handle a bunch or corner cases in denormalized floating point values that the h/w doesn't cover. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
