On 03/28/14 at 11:24am, Dave Young wrote:
+static void exclude_ram(struct memory_range *mr, int *nr_mr)
+{
+ int ranges, i, j, m;
+
+ ranges = *nr_mr;
+ for (i = 0, j = 0; i ranges; i++) {
+ if (mr[j].type == RANGE_RAM) {
+ dbgprintf(Remove
On 03/27/14 at 05:57pm, Vivek Goyal wrote:
On Thu, Mar 27, 2014 at 06:25:48PM +0800, WANG Chao wrote:
[..]
@@ -169,6 +200,31 @@ static int get_kernel_vaddr_and_size(struct kexec_info
*UNUSED(info),
}
}
}
+
+ /* Go through /proc/kcore again.
On 03/28/14 at 02:13pm, WANG Chao wrote:
On 03/28/14 at 11:24am, Dave Young wrote:
+static void exclude_ram(struct memory_range *mr, int *nr_mr)
+{
+ int ranges, i, j, m;
+
+ ranges = *nr_mr;
+ for (i = 0, j = 0; i ranges; i++) {
+ if (mr[j].type == RANGE_RAM) {
When kASLR is enabled (CONFIG_RANDOMIZED_BASE=y), kernel text mapping
base is randomized. The max base offset of such randomization is
configured at compile time through CONFIG_RANDOMIZE_MAX_BASE_OFFSET (by
default 1G).
Currently kexec-tools is using hard code macro X86_64__START_KERNEL_map
system ram and crash_reserved together before building EFL header.
There's already below code which ignore the ram ranges..
for (i = 0; i ranges; i++, range++) {
if (range-type != RANGE_RAM)
continue;
Hmm, this RANGE_RAM is converted from
On 03/28/14 at 02:43pm, Dave Young wrote:
On 03/28/14 at 02:13pm, WANG Chao wrote:
On 03/28/14 at 11:24am, Dave Young wrote:
+static void exclude_ram(struct memory_range *mr, int *nr_mr)
+{
+ int ranges, i, j, m;
+
+ ranges = *nr_mr;
+ for (i = 0,
Hello Petr,
Xen dumps fail, because the p2m mapping is initialized too late.
The dependency goes like this:
- Xen uses FLATMEM
- get_mm_flatmem() uses info-dom0_mapnr to initialize mm structures
- get_dom0_mapnr() needs p2m mappings to read from a VADDR
- the p2m list is initialized in
On Fri, 28 Mar 2014 08:18:13 +
Atsushi Kumagai kumagai-atsu...@mxc.nes.nec.co.jp wrote:
Hello Petr,
Xen dumps fail, because the p2m mapping is initialized too late.
The dependency goes like this:
- Xen uses FLATMEM
- get_mm_flatmem() uses info-dom0_mapnr to initialize mm structures
On Fri, 28 Mar 2014 08:18:13 +
Atsushi Kumagai kumagai-atsu...@mxc.nes.nec.co.jp wrote:
Hello Petr,
Xen dumps fail, because the p2m mapping is initialized too late.
The dependency goes like this:
- Xen uses FLATMEM
- get_mm_flatmem() uses info-dom0_mapnr to initialize mm structures
-
On Thu, 27 Mar 2014 14:54:41 +0100
Michael Holzheu holz...@linux.vnet.ibm.com wrote:
On Thu, 27 Mar 2014 05:19:06 +
Atsushi Kumagai kumagai-atsu...@mxc.nes.nec.co.jp wrote:
Hello Michael,
On Wed, 26 Mar 2014 10:55:07 +0100 (a/T)
HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote:
On 2014/3/27 22:04, Dave Anderson wrote:
- Original Message -
The patch series introduce LPAE support for user space
utility kexec(the last) and ARM linux kernel(the others).
I have tested the patch series in armA15 platform which have
more than 4G memory.
Hello Liu,
I'm
Trying to use makedumpfile on a Xen Dom0 ELF file currently fails, but there
are in fact only a few missing pieces. With the following two patches, I was
able to produce a dump even with high dump levels (-d17 and -d31).
Needless to say, this can reduce the size of Dom0 dumps considerably.
From: Petr Tesarik p...@tesarici.cz
Xen dumps fail, because the p2m mapping is initialized too late.
The dependency goes like this:
- Xen uses FLATMEM
- get_mm_flatmem() uses info-dom0_mapnr to initialize mm structures
- get_dom0_mapnr() needs p2m mappings to read from a VADDR
- the p2m list is
From: Petr Tesarik p...@tesarici.cz
Xen dumps fail, because the p2m mapping is initialized too late.
The dependency goes like this:
- Xen uses FLATMEM
- get_mm_flatmem() uses info-dom0_mapnr to initialize mm structures
- get_dom0_mapnr() needs p2m mappings to read from a VADDR
- the p2m list is
From: Petr Tesarik p...@tesarici.cz
If max_pfn symbol is not exported in the Dom0 kernel's VMCOREINFO, the
maximum PFN can be determined from the size of the mapping between PFN
and MFN.
Using this approach, filtering works for Xen kernels without debuginfo
(and even without adding more lines to
Trying to use makedumpfile on a Xen Dom0 ELF file currently fails, but there
are in fact only a few missing pieces. With the following two patches, I was
able to produce a dump even with high dump levels (-d17 and -d31).
Needless to say, this can reduce the size of Dom0 dumps considerably.
Petr
Trying to use makedumpfile on a Xen Dom0 ELF file currently fails, but there
are in fact only a few missing pieces. With the following two patches, I was
able to produce a dump even with high dump levels (-d17 and -d31).
Needless to say, this can reduce the size of Dom0 dumps considerably.
From: Petr Tesarik p...@tesarici.cz
If max_pfn symbol is not exported in the Dom0 kernel's VMCOREINFO, the
maximum PFN can be determined from the size of the mapping between PFN
and MFN.
Using this approach, filtering works for Xen kernels without debuginfo
(and even without adding more lines to
This patch fixs a bug if the size of an ELF segment less than 8 pages.
In function create_1st_bitmap_cyclic() and initialize_2nd_bitmap_cyclic(),
there are the same code:
pfn_start_roundup = roundup(pfn_start, BITPERBYTE);
pfn_end_round = round(pfn_end,
On 03/27/2014 09:20 AM, HATAYAMA Daisuke wrote:
Sorry. This was fixed by the following patch.
commit 4404368a0860e3b6c845eb41782e97a9bf7593b8
Author: WANG Chao chaow...@redhat.com
Date: Wed Dec 18 22:34:43 2013 +0900
[PATCH] memset() in cyclic bitmap initialization introduce segment
On Fri, Mar 28, 2014 at 01:23:49PM +0800, WANG Chao wrote:
[..]
And even if we have to, then why do we need to return pointer to
crash_memory_range array?
For historical reason, get_crash_memory_ranges() is not only set
crash_memory_range but also return the pointer of another copy of
On Friday, March 28, 2014 01:23:49 PM WANG Chao wrote:
On 03/27/14 at 06:32pm, Vivek Goyal wrote:
...
I was just trying to keep the change as minimal as possible, so that the
reviewers can be more clear of what the patch does instead of something
looks messed up.
Sounds very sane. I tried it
- Original Message -
On 2014/3/27 22:04, Dave Anderson wrote:
- Original Message -
The patch series introduce LPAE support for user space
utility kexec(the last) and ARM linux kernel(the others).
I have tested the patch series in armA15 platform which have
On Fri, Mar 28, 2014 at 04:44:33PM +0100, Thomas Renninger wrote:
[..]
But if you have no problem review it, I can do some
clean up within this patch. However I think it's better to be addressed
the cleanup in the future, or at least as a separated patch in this
series.
Seeing some
On Fri, 28 Mar 2014 12:00:47 +0100
Petr Tesarik ptesa...@suse.cz wrote:
On Thu, 27 Mar 2014 14:54:41 +0100
Michael Holzheu holz...@linux.vnet.ibm.com wrote:
[snip]
Here the fixed patch:
Thanks, I'll merge the fixed version into v1.5.6.
Great!
I'm sorry to spoil the party,
On Thu, Mar 27, 2014 at 01:47:15PM +0800, Dave Young wrote:
On 03/26/14 at 09:54pm, Tony Jones wrote:
On non-EFI systems, efi_info section of boot_params is zero filled
resulting
in an erroneous message from kexec regarding efi memory descriptor
version.
Caused by commit:
On Fri, Mar 28, 2014 at 10:05:22AM -0400, Vivek Goyal wrote:
On Fri, Mar 28, 2014 at 03:05:00PM +0800, WANG Chao wrote:
When kASLR is enabled (CONFIG_RANDOMIZED_BASE=y), kernel text mapping
base is randomized. The max base offset of such randomization is
configured at compile time through
On Thu, Mar 27, 2014 at 09:14:34AM +0800, Dave Young wrote:
On 03/25/14 at 12:09pm, Wang Nan wrote:
The main goal of this patch series is to pass initrd position to
secondary kernel. To makes code clear, patch 2/3 introduce a new
function to handle fdt related operations.
Without these
On Fri, Mar 28, 2014 at 03:05:00PM +0800, WANG Chao wrote:
When kASLR is enabled (CONFIG_RANDOMIZED_BASE=y), kernel text mapping
base is randomized. The max base offset of such randomization is
configured at compile time through CONFIG_RANDOMIZE_MAX_BASE_OFFSET (by
default 1G).
Currently
On Fri, 28 Mar 2014 17:46:22 +0100
Michael Holzheu holz...@linux.vnet.ibm.com wrote:
On Fri, 28 Mar 2014 12:00:47 +0100
Petr Tesarik ptesa...@suse.cz wrote:
[snip]
That's because the bitmap length is calculated in prepare_bitmap_buffer
using info-max_mapnr, but create_1st_bitmap() still
On Fri, 28 Mar 2014 12:00:47 +0100
Petr Tesarik ptesa...@suse.cz wrote:
On Thu, 27 Mar 2014 14:54:41 +0100
Michael Holzheu holz...@linux.vnet.ibm.com wrote:
On Thu, 27 Mar 2014 05:19:06 +
Atsushi Kumagai kumagai-atsu...@mxc.nes.nec.co.jp wrote:
Hello Michael,
On Wed, 26
On Fri, Mar 28, 2014 at 12:52:54PM +0800, WANG Chao wrote:
[..]
+static void add_setup_data(struct kexec_info *info,
+struct x86_linux_param_header *real_mode,
+struct setup_data *sd)
+{
What is setup_data? A little comment above function
32 matches
Mail list logo
