* [RFC PATCH 0/2] transfer sparse memory related values @ 2014-05-07 13:27 ` Liu Hua 0 siblings, 0 replies; 16+ messages in thread From: Liu Hua @ 2014-05-07 13:27 UTC (permalink / raw) To: linux, kumagai-atsushi Cc: wangnan0, peifeiyue, sdu.liu, will.deacon, liusdu, kexec, linux-kernel Now different platforms may have different SECTION_SIZE_BITS and MAX_PHYSMEM_BITS. But linux passes nothing related to the vmcore. User space tools such as makedumpfile needs these to deal with the vmcore. So we must define these when compiling. So if we deal with aother vmcore. We may need to recompile the tools. These patch series make kernel pass related infomation to the user space tools, via vmcore. And makedumpfile can get these when parsing vmcore. So the makdumpfile becomes more compatible to vmcore with different section size. Liu Hua (1): kdump: add sparse memory related values to vmcore makedumpfile: get additional information from vmcore kernel/kexec.c | 3 +++ makedumpfile.c | 17 +++++++++++++++++ makedumpfile.h | 2 ++ 3 files changed, 22 insertions(+) -- 1.9.0 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 16+ messages in thread
* [RFC PATCH 0/2] transfer sparse memory related values @ 2014-05-07 13:27 ` Liu Hua 0 siblings, 0 replies; 16+ messages in thread From: Liu Hua @ 2014-05-07 13:27 UTC (permalink / raw) To: linux, kumagai-atsushi Cc: will.deacon, kexec, linux-kernel, wangnan0, peifeiyue, sdu.liu, liusdu Now different platforms may have different SECTION_SIZE_BITS and MAX_PHYSMEM_BITS. But linux passes nothing related to the vmcore. User space tools such as makedumpfile needs these to deal with the vmcore. So we must define these when compiling. So if we deal with aother vmcore. We may need to recompile the tools. These patch series make kernel pass related infomation to the user space tools, via vmcore. And makedumpfile can get these when parsing vmcore. So the makdumpfile becomes more compatible to vmcore with different section size. Liu Hua (1): kdump: add sparse memory related values to vmcore makedumpfile: get additional information from vmcore kernel/kexec.c | 3 +++ makedumpfile.c | 17 +++++++++++++++++ makedumpfile.h | 2 ++ 3 files changed, 22 insertions(+) -- 1.9.0 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [RFC PATCH 1/2] kdump: add sparse memory related values to vmcore 2014-05-07 13:27 ` Liu Hua @ 2014-05-07 13:27 ` Liu Hua -1 siblings, 0 replies; 16+ messages in thread From: Liu Hua @ 2014-05-07 13:27 UTC (permalink / raw) To: linux, kumagai-atsushi Cc: wangnan0, peifeiyue, sdu.liu, will.deacon, liusdu, kexec, linux-kernel Now different platforms may have different sparse memory related values, such as MAX_PHYSMEM_SIZE and SECTION_SIZE_BITS. And user tools such as makedumpfile can not get these values from the vmcore. It defines these value as macros. If we use makedumpfile to treate with vmcores with different SECTION size. We must recompile it. It is awaste of time. So this patch add related values to vmcore to notify the user space tools to deal with this situation. Signed-off-by: Liu Hua <sdu.liu@huawei.com> --- kernel/kexec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/kexec.c b/kernel/kexec.c index bf0b929e..96f7c5b 100644 --- a/kernel/kexec.c +++ b/kernel/kexec.c @@ -1577,6 +1577,9 @@ static int __init crash_save_vmcoreinfo_init(void) VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); VMCOREINFO_STRUCT_SIZE(mem_section); VMCOREINFO_OFFSET(mem_section, section_mem_map); + VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS); + VMCOREINFO_NUMBER(SECTION_SIZE_BITS); + #endif VMCOREINFO_STRUCT_SIZE(page); VMCOREINFO_STRUCT_SIZE(pglist_data); -- 1.9.0 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [RFC PATCH 1/2] kdump: add sparse memory related values to vmcore @ 2014-05-07 13:27 ` Liu Hua 0 siblings, 0 replies; 16+ messages in thread From: Liu Hua @ 2014-05-07 13:27 UTC (permalink / raw) To: linux, kumagai-atsushi Cc: will.deacon, kexec, linux-kernel, wangnan0, peifeiyue, sdu.liu, liusdu Now different platforms may have different sparse memory related values, such as MAX_PHYSMEM_SIZE and SECTION_SIZE_BITS. And user tools such as makedumpfile can not get these values from the vmcore. It defines these value as macros. If we use makedumpfile to treate with vmcores with different SECTION size. We must recompile it. It is awaste of time. So this patch add related values to vmcore to notify the user space tools to deal with this situation. Signed-off-by: Liu Hua <sdu.liu@huawei.com> --- kernel/kexec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/kexec.c b/kernel/kexec.c index bf0b929e..96f7c5b 100644 --- a/kernel/kexec.c +++ b/kernel/kexec.c @@ -1577,6 +1577,9 @@ static int __init crash_save_vmcoreinfo_init(void) VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); VMCOREINFO_STRUCT_SIZE(mem_section); VMCOREINFO_OFFSET(mem_section, section_mem_map); + VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS); + VMCOREINFO_NUMBER(SECTION_SIZE_BITS); + #endif VMCOREINFO_STRUCT_SIZE(page); VMCOREINFO_STRUCT_SIZE(pglist_data); -- 1.9.0 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [RFC PATCH 2/2] makedumpfile: get additional information from vmcore 2014-05-07 13:27 ` Liu Hua @ 2014-05-07 13:27 ` Liu Hua -1 siblings, 0 replies; 16+ messages in thread From: Liu Hua @ 2014-05-07 13:27 UTC (permalink / raw) To: linux, kumagai-atsushi Cc: wangnan0, peifeiyue, sdu.liu, will.deacon, liusdu, kexec, linux-kernel Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as macros. So if we deal with vmcores with different values of these two macros. We have to recompile makedumpfile. This patch makes makedumpfile get these two values from vmcore info, if existing. It makes the makedumpfile more compatible to vmcores with different section size. Signed-off-by: Liu Hua <sdu.liu@huawei.com> --- makedumpfile.c | 17 +++++++++++++++++ makedumpfile.h | 2 ++ 2 files changed, 19 insertions(+) diff --git a/makedumpfile.c b/makedumpfile.c index 6cf6e24..3cdf323 100644 --- a/makedumpfile.c +++ b/makedumpfile.c @@ -2111,6 +2111,8 @@ read_vmcoreinfo(void) READ_NUMBER("PG_slab", PG_slab); READ_NUMBER("PG_buddy", PG_buddy); READ_NUMBER("PG_hwpoison", PG_hwpoison); + READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS); + READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS); READ_SRCFILE("pud_t", pud_t); @@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void) } int +calibrate_machdep_info(void) +{ + if (NUMBER(MAX_PHYSMEM_BITS) > 0) + info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS); + + if (NUMBER(SECTION_SIZE_BITS) > 0) + info->section_size_bits = NUMBER(SECTION_SIZE_BITS); + + return TRUE; +} + +int initial(void) { off_t offset; @@ -3214,6 +3228,9 @@ out: if (debug_info && !get_machdep_info()) return FALSE; + if (debug_info && !calibrate_machdep_info()) + return FALSE; + if (is_xen_memory() && !get_dom0_mapnr()) return FALSE; diff --git a/makedumpfile.h b/makedumpfile.h index eb03688..7acb23a 100644 --- a/makedumpfile.h +++ b/makedumpfile.h @@ -1434,6 +1434,8 @@ struct number_table { long PG_hwpoison; long PAGE_BUDDY_MAPCOUNT_VALUE; + long SECTION_SIZE_BITS; + long MAX_PHYSMEM_BITS; }; struct srcfile_table { -- 1.9.0 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [RFC PATCH 2/2] makedumpfile: get additional information from vmcore @ 2014-05-07 13:27 ` Liu Hua 0 siblings, 0 replies; 16+ messages in thread From: Liu Hua @ 2014-05-07 13:27 UTC (permalink / raw) To: linux, kumagai-atsushi Cc: will.deacon, kexec, linux-kernel, wangnan0, peifeiyue, sdu.liu, liusdu Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as macros. So if we deal with vmcores with different values of these two macros. We have to recompile makedumpfile. This patch makes makedumpfile get these two values from vmcore info, if existing. It makes the makedumpfile more compatible to vmcores with different section size. Signed-off-by: Liu Hua <sdu.liu@huawei.com> --- makedumpfile.c | 17 +++++++++++++++++ makedumpfile.h | 2 ++ 2 files changed, 19 insertions(+) diff --git a/makedumpfile.c b/makedumpfile.c index 6cf6e24..3cdf323 100644 --- a/makedumpfile.c +++ b/makedumpfile.c @@ -2111,6 +2111,8 @@ read_vmcoreinfo(void) READ_NUMBER("PG_slab", PG_slab); READ_NUMBER("PG_buddy", PG_buddy); READ_NUMBER("PG_hwpoison", PG_hwpoison); + READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS); + READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS); READ_SRCFILE("pud_t", pud_t); @@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void) } int +calibrate_machdep_info(void) +{ + if (NUMBER(MAX_PHYSMEM_BITS) > 0) + info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS); + + if (NUMBER(SECTION_SIZE_BITS) > 0) + info->section_size_bits = NUMBER(SECTION_SIZE_BITS); + + return TRUE; +} + +int initial(void) { off_t offset; @@ -3214,6 +3228,9 @@ out: if (debug_info && !get_machdep_info()) return FALSE; + if (debug_info && !calibrate_machdep_info()) + return FALSE; + if (is_xen_memory() && !get_dom0_mapnr()) return FALSE; diff --git a/makedumpfile.h b/makedumpfile.h index eb03688..7acb23a 100644 --- a/makedumpfile.h +++ b/makedumpfile.h @@ -1434,6 +1434,8 @@ struct number_table { long PG_hwpoison; long PAGE_BUDDY_MAPCOUNT_VALUE; + long SECTION_SIZE_BITS; + long MAX_PHYSMEM_BITS; }; struct srcfile_table { -- 1.9.0 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* RE: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore 2014-05-07 13:27 ` Liu Hua @ 2014-05-13 6:21 ` Atsushi Kumagai -1 siblings, 0 replies; 16+ messages in thread From: Atsushi Kumagai @ 2014-05-13 6:21 UTC (permalink / raw) To: sdu.liu@huawei.com, linux@arm.linux.org.uk Cc: wangnan0@huawei.com, peifeiyue@huawei.com, will.deacon@arm.com, liusdu@126.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org Hello Liu, >Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as >macros. So if we deal with vmcores with different values >of these two macros. We have to recompile makedumpfile. There are other macros which have architecture-specific values (e.g. __PAGE_OFFSET), and some functions are specific to each architecture (e.g. vaddr_to_paddr()), so we need recompilation eventually. OTOH, we already don't need recompilation for the same architecture since the values of such macros are defined for each kernel version like below: #ifdef __x86_64__ ... #define _MAX_PHYSMEM_BITS_ORIG (40) #define _MAX_PHYSMEM_BITS_2_6_26 (44) #define _MAX_PHYSMEM_BITS_2_6_31 (46) So I don't think this patch is valuable. Thanks Atsushi Kumagai >This patch makes makedumpfile get these two values from >vmcore info, if existing. It makes the makedumpfile more >compatible to vmcores with different section size. > >Signed-off-by: Liu Hua <sdu.liu@huawei.com> >--- > makedumpfile.c | 17 +++++++++++++++++ > makedumpfile.h | 2 ++ > 2 files changed, 19 insertions(+) > >diff --git a/makedumpfile.c b/makedumpfile.c >index 6cf6e24..3cdf323 100644 >--- a/makedumpfile.c >+++ b/makedumpfile.c >@@ -2111,6 +2111,8 @@ read_vmcoreinfo(void) > READ_NUMBER("PG_slab", PG_slab); > READ_NUMBER("PG_buddy", PG_buddy); > READ_NUMBER("PG_hwpoison", PG_hwpoison); >+ READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS); >+ READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS); > > READ_SRCFILE("pud_t", pud_t); > >@@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void) > } > > int >+calibrate_machdep_info(void) >+{ >+ if (NUMBER(MAX_PHYSMEM_BITS) > 0) >+ info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS); >+ >+ if (NUMBER(SECTION_SIZE_BITS) > 0) >+ info->section_size_bits = NUMBER(SECTION_SIZE_BITS); >+ >+ return TRUE; >+} >+ >+int > initial(void) > { > off_t offset; >@@ -3214,6 +3228,9 @@ out: > if (debug_info && !get_machdep_info()) > return FALSE; > >+ if (debug_info && !calibrate_machdep_info()) >+ return FALSE; >+ > if (is_xen_memory() && !get_dom0_mapnr()) > return FALSE; > >diff --git a/makedumpfile.h b/makedumpfile.h >index eb03688..7acb23a 100644 >--- a/makedumpfile.h >+++ b/makedumpfile.h >@@ -1434,6 +1434,8 @@ struct number_table { > long PG_hwpoison; > > long PAGE_BUDDY_MAPCOUNT_VALUE; >+ long SECTION_SIZE_BITS; >+ long MAX_PHYSMEM_BITS; > }; > > struct srcfile_table { >-- >1.9.0 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore @ 2014-05-13 6:21 ` Atsushi Kumagai 0 siblings, 0 replies; 16+ messages in thread From: Atsushi Kumagai @ 2014-05-13 6:21 UTC (permalink / raw) To: sdu.liu@huawei.com, linux@arm.linux.org.uk Cc: will.deacon@arm.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, wangnan0@huawei.com, peifeiyue@huawei.com, liusdu@126.com Hello Liu, >Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as >macros. So if we deal with vmcores with different values >of these two macros. We have to recompile makedumpfile. There are other macros which have architecture-specific values (e.g. __PAGE_OFFSET), and some functions are specific to each architecture (e.g. vaddr_to_paddr()), so we need recompilation eventually. OTOH, we already don't need recompilation for the same architecture since the values of such macros are defined for each kernel version like below: #ifdef __x86_64__ ... #define _MAX_PHYSMEM_BITS_ORIG (40) #define _MAX_PHYSMEM_BITS_2_6_26 (44) #define _MAX_PHYSMEM_BITS_2_6_31 (46) So I don't think this patch is valuable. Thanks Atsushi Kumagai >This patch makes makedumpfile get these two values from >vmcore info, if existing. It makes the makedumpfile more >compatible to vmcores with different section size. > >Signed-off-by: Liu Hua <sdu.liu@huawei.com> >--- > makedumpfile.c | 17 +++++++++++++++++ > makedumpfile.h | 2 ++ > 2 files changed, 19 insertions(+) > >diff --git a/makedumpfile.c b/makedumpfile.c >index 6cf6e24..3cdf323 100644 >--- a/makedumpfile.c >+++ b/makedumpfile.c >@@ -2111,6 +2111,8 @@ read_vmcoreinfo(void) > READ_NUMBER("PG_slab", PG_slab); > READ_NUMBER("PG_buddy", PG_buddy); > READ_NUMBER("PG_hwpoison", PG_hwpoison); >+ READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS); >+ READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS); > > READ_SRCFILE("pud_t", pud_t); > >@@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void) > } > > int >+calibrate_machdep_info(void) >+{ >+ if (NUMBER(MAX_PHYSMEM_BITS) > 0) >+ info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS); >+ >+ if (NUMBER(SECTION_SIZE_BITS) > 0) >+ info->section_size_bits = NUMBER(SECTION_SIZE_BITS); >+ >+ return TRUE; >+} >+ >+int > initial(void) > { > off_t offset; >@@ -3214,6 +3228,9 @@ out: > if (debug_info && !get_machdep_info()) > return FALSE; > >+ if (debug_info && !calibrate_machdep_info()) >+ return FALSE; >+ > if (is_xen_memory() && !get_dom0_mapnr()) > return FALSE; > >diff --git a/makedumpfile.h b/makedumpfile.h >index eb03688..7acb23a 100644 >--- a/makedumpfile.h >+++ b/makedumpfile.h >@@ -1434,6 +1434,8 @@ struct number_table { > long PG_hwpoison; > > long PAGE_BUDDY_MAPCOUNT_VALUE; >+ long SECTION_SIZE_BITS; >+ long MAX_PHYSMEM_BITS; > }; > > struct srcfile_table { >-- >1.9.0 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore 2014-05-13 6:21 ` Atsushi Kumagai @ 2014-05-13 7:25 ` Liu hua -1 siblings, 0 replies; 16+ messages in thread From: Liu hua @ 2014-05-13 7:25 UTC (permalink / raw) To: Atsushi Kumagai, linux@arm.linux.org.uk Cc: wangnan0@huawei.com, peifeiyue@huawei.com, will.deacon@arm.com, liusdu@126.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org On 2014/5/13 14:21, Atsushi Kumagai wrote: > Hello Liu, > >> Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as >> macros. So if we deal with vmcores with different values >> of these two macros. We have to recompile makedumpfile. > > There are other macros which have architecture-specific values > (e.g. __PAGE_OFFSET), and some functions are specific to each > architecture (e.g. vaddr_to_paddr()), so we need recompilation > eventually. > > OTOH, we already don't need recompilation for the same architecture > since the values of such macros are defined for each kernel version > like below: > > #ifdef __x86_64__ > ... > #define _MAX_PHYSMEM_BITS_ORIG (40) > #define _MAX_PHYSMEM_BITS_2_6_26 (44) > #define _MAX_PHYSMEM_BITS_2_6_31 (46) > > So I don't think this patch is valuable. Hi Atsushi, For x86, it is not necessory. But for arm, different venders may define different SECTION_SIZE_BITS. for example: 1 arch/arm/mach-clps711x/include/mach/memory.h #define SECTION_SIZE_BITS 24 2 arch/arm/mach-exynos/include/mach/memory.h #define SECTION_SIZE_BITS 28 4 arch/arm/mach-hisi/include/mach/memory.h #define SECTION_SIZE_BITS 26 8 arch/arm/mach-sa1100/include/mach/memory.h #define SECTION_SIZE_BITS 27 Perhaps we should find another way to let the userspace tools to get the architecture-specific values. Liu Hua > > > Thanks > Atsushi Kumagai > >> This patch makes makedumpfile get these two values from >> vmcore info, if existing. It makes the makedumpfile more >> compatible to vmcores with different section size. >> >> Signed-off-by: Liu Hua <sdu.liu@huawei.com> >> --- >> makedumpfile.c | 17 +++++++++++++++++ >> makedumpfile.h | 2 ++ >> 2 files changed, 19 insertions(+) >> >> diff --git a/makedumpfile.c b/makedumpfile.c >> index 6cf6e24..3cdf323 100644 >> --- a/makedumpfile.c >> +++ b/makedumpfile.c >> @@ -2111,6 +2111,8 @@ read_vmcoreinfo(void) >> READ_NUMBER("PG_slab", PG_slab); >> READ_NUMBER("PG_buddy", PG_buddy); >> READ_NUMBER("PG_hwpoison", PG_hwpoison); >> + READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS); >> + READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS); >> >> READ_SRCFILE("pud_t", pud_t); >> >> @@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void) >> } >> >> int >> +calibrate_machdep_info(void) >> +{ >> + if (NUMBER(MAX_PHYSMEM_BITS) > 0) >> + info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS); >> + >> + if (NUMBER(SECTION_SIZE_BITS) > 0) >> + info->section_size_bits = NUMBER(SECTION_SIZE_BITS); >> + >> + return TRUE; >> +} >> + >> +int >> initial(void) >> { >> off_t offset; >> @@ -3214,6 +3228,9 @@ out: >> if (debug_info && !get_machdep_info()) >> return FALSE; >> >> + if (debug_info && !calibrate_machdep_info()) >> + return FALSE; >> + >> if (is_xen_memory() && !get_dom0_mapnr()) >> return FALSE; >> >> diff --git a/makedumpfile.h b/makedumpfile.h >> index eb03688..7acb23a 100644 >> --- a/makedumpfile.h >> +++ b/makedumpfile.h >> @@ -1434,6 +1434,8 @@ struct number_table { >> long PG_hwpoison; >> >> long PAGE_BUDDY_MAPCOUNT_VALUE; >> + long SECTION_SIZE_BITS; >> + long MAX_PHYSMEM_BITS; >> }; >> >> struct srcfile_table { >> -- >> 1.9.0 > > . > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore @ 2014-05-13 7:25 ` Liu hua 0 siblings, 0 replies; 16+ messages in thread From: Liu hua @ 2014-05-13 7:25 UTC (permalink / raw) To: Atsushi Kumagai, linux@arm.linux.org.uk Cc: will.deacon@arm.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, wangnan0@huawei.com, peifeiyue@huawei.com, liusdu@126.com On 2014/5/13 14:21, Atsushi Kumagai wrote: > Hello Liu, > >> Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as >> macros. So if we deal with vmcores with different values >> of these two macros. We have to recompile makedumpfile. > > There are other macros which have architecture-specific values > (e.g. __PAGE_OFFSET), and some functions are specific to each > architecture (e.g. vaddr_to_paddr()), so we need recompilation > eventually. > > OTOH, we already don't need recompilation for the same architecture > since the values of such macros are defined for each kernel version > like below: > > #ifdef __x86_64__ > ... > #define _MAX_PHYSMEM_BITS_ORIG (40) > #define _MAX_PHYSMEM_BITS_2_6_26 (44) > #define _MAX_PHYSMEM_BITS_2_6_31 (46) > > So I don't think this patch is valuable. Hi Atsushi, For x86, it is not necessory. But for arm, different venders may define different SECTION_SIZE_BITS. for example: 1 arch/arm/mach-clps711x/include/mach/memory.h #define SECTION_SIZE_BITS 24 2 arch/arm/mach-exynos/include/mach/memory.h #define SECTION_SIZE_BITS 28 4 arch/arm/mach-hisi/include/mach/memory.h #define SECTION_SIZE_BITS 26 8 arch/arm/mach-sa1100/include/mach/memory.h #define SECTION_SIZE_BITS 27 Perhaps we should find another way to let the userspace tools to get the architecture-specific values. Liu Hua > > > Thanks > Atsushi Kumagai > >> This patch makes makedumpfile get these two values from >> vmcore info, if existing. It makes the makedumpfile more >> compatible to vmcores with different section size. >> >> Signed-off-by: Liu Hua <sdu.liu@huawei.com> >> --- >> makedumpfile.c | 17 +++++++++++++++++ >> makedumpfile.h | 2 ++ >> 2 files changed, 19 insertions(+) >> >> diff --git a/makedumpfile.c b/makedumpfile.c >> index 6cf6e24..3cdf323 100644 >> --- a/makedumpfile.c >> +++ b/makedumpfile.c >> @@ -2111,6 +2111,8 @@ read_vmcoreinfo(void) >> READ_NUMBER("PG_slab", PG_slab); >> READ_NUMBER("PG_buddy", PG_buddy); >> READ_NUMBER("PG_hwpoison", PG_hwpoison); >> + READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS); >> + READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS); >> >> READ_SRCFILE("pud_t", pud_t); >> >> @@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void) >> } >> >> int >> +calibrate_machdep_info(void) >> +{ >> + if (NUMBER(MAX_PHYSMEM_BITS) > 0) >> + info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS); >> + >> + if (NUMBER(SECTION_SIZE_BITS) > 0) >> + info->section_size_bits = NUMBER(SECTION_SIZE_BITS); >> + >> + return TRUE; >> +} >> + >> +int >> initial(void) >> { >> off_t offset; >> @@ -3214,6 +3228,9 @@ out: >> if (debug_info && !get_machdep_info()) >> return FALSE; >> >> + if (debug_info && !calibrate_machdep_info()) >> + return FALSE; >> + >> if (is_xen_memory() && !get_dom0_mapnr()) >> return FALSE; >> >> diff --git a/makedumpfile.h b/makedumpfile.h >> index eb03688..7acb23a 100644 >> --- a/makedumpfile.h >> +++ b/makedumpfile.h >> @@ -1434,6 +1434,8 @@ struct number_table { >> long PG_hwpoison; >> >> long PAGE_BUDDY_MAPCOUNT_VALUE; >> + long SECTION_SIZE_BITS; >> + long MAX_PHYSMEM_BITS; >> }; >> >> struct srcfile_table { >> -- >> 1.9.0 > > . > ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore 2014-05-13 7:25 ` Liu hua @ 2014-05-14 7:53 ` Atsushi Kumagai -1 siblings, 0 replies; 16+ messages in thread From: Atsushi Kumagai @ 2014-05-14 7:53 UTC (permalink / raw) To: sdu.liu@huawei.com, linux@arm.linux.org.uk Cc: wangnan0@huawei.com, peifeiyue@huawei.com, will.deacon@arm.com, liusdu@126.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org >On 2014/5/13 14:21, Atsushi Kumagai wrote: >> Hello Liu, >> >>> Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as >>> macros. So if we deal with vmcores with different values >>> of these two macros. We have to recompile makedumpfile. >> >> There are other macros which have architecture-specific values >> (e.g. __PAGE_OFFSET), and some functions are specific to each >> architecture (e.g. vaddr_to_paddr()), so we need recompilation >> eventually. >> >> OTOH, we already don't need recompilation for the same architecture >> since the values of such macros are defined for each kernel version >> like below: >> >> #ifdef __x86_64__ >> ... >> #define _MAX_PHYSMEM_BITS_ORIG (40) >> #define _MAX_PHYSMEM_BITS_2_6_26 (44) >> #define _MAX_PHYSMEM_BITS_2_6_31 (46) >> >> So I don't think this patch is valuable. > >Hi Atsushi, > >For x86, it is not necessory. But for arm, different venders >may define different SECTION_SIZE_BITS. for example: > > 1 arch/arm/mach-clps711x/include/mach/memory.h > #define SECTION_SIZE_BITS 24 > 2 arch/arm/mach-exynos/include/mach/memory.h > #define SECTION_SIZE_BITS 28 > 4 arch/arm/mach-hisi/include/mach/memory.h > #define SECTION_SIZE_BITS 26 > 8 arch/arm/mach-sa1100/include/mach/memory.h > #define SECTION_SIZE_BITS 27 > >Perhaps we should find another way to let the userspace tools >to get the architecture-specific values. I see, I think this description is better than the first one. Now, makedumpfile can't get an appropriate values of the two macros since the values are variable even if the architecture and the kernel version are fixed (at least for arm), and we can't solve this without *manual code fixing*, right? In practice, the current code expects that all arm machines adopt Exynos processors, this is an problem definitely. #ifdef __arm__ #define KVBASE_MASK (0xffff) #define KVBASE (SYMBOL(_stext) & ~KVBASE_MASK) #define _SECTION_SIZE_BITS (28) #define _MAX_PHYSMEM_BITS (32) I think it's better to fix the descriptions to get acceptability, but this patch is necessary from the view point of makedumpfile. So I recommend you to repost this patch set, then I'll accept it. Thanks Atsushi Kumagai >> >>> This patch makes makedumpfile get these two values from >>> vmcore info, if existing. It makes the makedumpfile more >>> compatible to vmcores with different section size. >>> >>> Signed-off-by: Liu Hua <sdu.liu@huawei.com> >>> --- >>> makedumpfile.c | 17 +++++++++++++++++ >>> makedumpfile.h | 2 ++ >>> 2 files changed, 19 insertions(+) >>> >>> diff --git a/makedumpfile.c b/makedumpfile.c >>> index 6cf6e24..3cdf323 100644 >>> --- a/makedumpfile.c >>> +++ b/makedumpfile.c >>> @@ -2111,6 +2111,8 @@ read_vmcoreinfo(void) >>> READ_NUMBER("PG_slab", PG_slab); >>> READ_NUMBER("PG_buddy", PG_buddy); >>> READ_NUMBER("PG_hwpoison", PG_hwpoison); >>> + READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS); >>> + READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS); >>> >>> READ_SRCFILE("pud_t", pud_t); >>> >>> @@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void) >>> } >>> >>> int >>> +calibrate_machdep_info(void) >>> +{ >>> + if (NUMBER(MAX_PHYSMEM_BITS) > 0) >>> + info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS); >>> + >>> + if (NUMBER(SECTION_SIZE_BITS) > 0) >>> + info->section_size_bits = NUMBER(SECTION_SIZE_BITS); >>> + >>> + return TRUE; >>> +} >>> + >>> +int >>> initial(void) >>> { >>> off_t offset; >>> @@ -3214,6 +3228,9 @@ out: >>> if (debug_info && !get_machdep_info()) >>> return FALSE; >>> >>> + if (debug_info && !calibrate_machdep_info()) >>> + return FALSE; >>> + >>> if (is_xen_memory() && !get_dom0_mapnr()) >>> return FALSE; >>> >>> diff --git a/makedumpfile.h b/makedumpfile.h >>> index eb03688..7acb23a 100644 >>> --- a/makedumpfile.h >>> +++ b/makedumpfile.h >>> @@ -1434,6 +1434,8 @@ struct number_table { >>> long PG_hwpoison; >>> >>> long PAGE_BUDDY_MAPCOUNT_VALUE; >>> + long SECTION_SIZE_BITS; >>> + long MAX_PHYSMEM_BITS; >>> }; >>> >>> struct srcfile_table { >>> -- >>> 1.9.0 >> >> . >> > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore @ 2014-05-14 7:53 ` Atsushi Kumagai 0 siblings, 0 replies; 16+ messages in thread From: Atsushi Kumagai @ 2014-05-14 7:53 UTC (permalink / raw) To: sdu.liu@huawei.com, linux@arm.linux.org.uk Cc: will.deacon@arm.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, wangnan0@huawei.com, peifeiyue@huawei.com, liusdu@126.com [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4273 bytes --] >On 2014/5/13 14:21, Atsushi Kumagai wrote: >> Hello Liu, >> >>> Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as >>> macros. So if we deal with vmcores with different values >>> of these two macros. We have to recompile makedumpfile. >> >> There are other macros which have architecture-specific values >> (e.g. __PAGE_OFFSET), and some functions are specific to each >> architecture (e.g. vaddr_to_paddr()), so we need recompilation >> eventually. >> >> OTOH, we already don't need recompilation for the same architecture >> since the values of such macros are defined for each kernel version >> like below: >> >> #ifdef __x86_64__ >> ... >> #define _MAX_PHYSMEM_BITS_ORIG (40) >> #define _MAX_PHYSMEM_BITS_2_6_26 (44) >> #define _MAX_PHYSMEM_BITS_2_6_31 (46) >> >> So I don't think this patch is valuable. > >Hi Atsushi, > >For x86, it is not necessory. But for arm, different venders >may define different SECTION_SIZE_BITS. for example: > > 1 arch/arm/mach-clps711x/include/mach/memory.h > #define SECTION_SIZE_BITS 24 > 2 arch/arm/mach-exynos/include/mach/memory.h > #define SECTION_SIZE_BITS 28 > 4 arch/arm/mach-hisi/include/mach/memory.h > #define SECTION_SIZE_BITS 26 > 8 arch/arm/mach-sa1100/include/mach/memory.h > #define SECTION_SIZE_BITS 27 > >Perhaps we should find another way to let the userspace tools >to get the architecture-specific values. I see, I think this description is better than the first one. Now, makedumpfile can't get an appropriate values of the two macros since the values are variable even if the architecture and the kernel version are fixed (at least for arm), and we can't solve this without *manual code fixing*, right? In practice, the current code expects that all arm machines adopt Exynos processors, this is an problem definitely. #ifdef __arm__ #define KVBASE_MASK (0xffff) #define KVBASE (SYMBOL(_stext) & ~KVBASE_MASK) #define _SECTION_SIZE_BITS (28) #define _MAX_PHYSMEM_BITS (32) I think it's better to fix the descriptions to get acceptability, but this patch is necessary from the view point of makedumpfile. So I recommend you to repost this patch set, then I'll accept it. Thanks Atsushi Kumagai >> >>> This patch makes makedumpfile get these two values from >>> vmcore info, if existing. It makes the makedumpfile more >>> compatible to vmcores with different section size. >>> >>> Signed-off-by: Liu Hua <sdu.liu@huawei.com> >>> --- >>> makedumpfile.c | 17 +++++++++++++++++ >>> makedumpfile.h | 2 ++ >>> 2 files changed, 19 insertions(+) >>> >>> diff --git a/makedumpfile.c b/makedumpfile.c >>> index 6cf6e24..3cdf323 100644 >>> --- a/makedumpfile.c >>> +++ b/makedumpfile.c >>> @@ -2111,6 +2111,8 @@ read_vmcoreinfo(void) >>> READ_NUMBER("PG_slab", PG_slab); >>> READ_NUMBER("PG_buddy", PG_buddy); >>> READ_NUMBER("PG_hwpoison", PG_hwpoison); >>> + READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS); >>> + READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS); >>> >>> READ_SRCFILE("pud_t", pud_t); >>> >>> @@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void) >>> } >>> >>> int >>> +calibrate_machdep_info(void) >>> +{ >>> + if (NUMBER(MAX_PHYSMEM_BITS) > 0) >>> + info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS); >>> + >>> + if (NUMBER(SECTION_SIZE_BITS) > 0) >>> + info->section_size_bits = NUMBER(SECTION_SIZE_BITS); >>> + >>> + return TRUE; >>> +} >>> + >>> +int >>> initial(void) >>> { >>> off_t offset; >>> @@ -3214,6 +3228,9 @@ out: >>> if (debug_info && !get_machdep_info()) >>> return FALSE; >>> >>> + if (debug_info && !calibrate_machdep_info()) >>> + return FALSE; >>> + >>> if (is_xen_memory() && !get_dom0_mapnr()) >>> return FALSE; >>> >>> diff --git a/makedumpfile.h b/makedumpfile.h >>> index eb03688..7acb23a 100644 >>> --- a/makedumpfile.h >>> +++ b/makedumpfile.h >>> @@ -1434,6 +1434,8 @@ struct number_table { >>> long PG_hwpoison; >>> >>> long PAGE_BUDDY_MAPCOUNT_VALUE; >>> + long SECTION_SIZE_BITS; >>> + long MAX_PHYSMEM_BITS; >>> }; >>> >>> struct srcfile_table { >>> -- >>> 1.9.0 >> >> . >> > ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore 2014-05-14 7:53 ` Atsushi Kumagai @ 2014-05-14 12:33 ` Liu hua -1 siblings, 0 replies; 16+ messages in thread From: Liu hua @ 2014-05-14 12:33 UTC (permalink / raw) To: Atsushi Kumagai, linux@arm.linux.org.uk Cc: wangnan0@huawei.com, peifeiyue@huawei.com, will.deacon@arm.com, liusdu@126.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org 于 2014/5/14 15:53, Atsushi Kumagai 写道: >> On 2014/5/13 14:21, Atsushi Kumagai wrote: >>> Hello Liu, >>> >>>> Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as >>>> macros. So if we deal with vmcores with different values >>>> of these two macros. We have to recompile makedumpfile. >>> >>> There are other macros which have architecture-specific values >>> (e.g. __PAGE_OFFSET), and some functions are specific to each >>> architecture (e.g. vaddr_to_paddr()), so we need recompilation >>> eventually. >>> >>> OTOH, we already don't need recompilation for the same architecture >>> since the values of such macros are defined for each kernel version >>> like below: >>> >>> #ifdef __x86_64__ >>> ... >>> #define _MAX_PHYSMEM_BITS_ORIG (40) >>> #define _MAX_PHYSMEM_BITS_2_6_26 (44) >>> #define _MAX_PHYSMEM_BITS_2_6_31 (46) >>> >>> So I don't think this patch is valuable. >> >> Hi Atsushi, >> >> For x86, it is not necessory. But for arm, different venders >> may define different SECTION_SIZE_BITS. for example: >> >> 1 arch/arm/mach-clps711x/include/mach/memory.h >> #define SECTION_SIZE_BITS 24 >> 2 arch/arm/mach-exynos/include/mach/memory.h >> #define SECTION_SIZE_BITS 28 >> 4 arch/arm/mach-hisi/include/mach/memory.h >> #define SECTION_SIZE_BITS 26 >> 8 arch/arm/mach-sa1100/include/mach/memory.h >> #define SECTION_SIZE_BITS 27 >> >> Perhaps we should find another way to let the userspace tools >> to get the architecture-specific values. > > I see, I think this description is better than the first one. > > Now, makedumpfile can't get an appropriate values of the two macros since the > values are variable even if the architecture and the kernel version are fixed > (at least for arm), and we can't solve this without *manual code fixing*, right? > > In practice, the current code expects that all arm machines adopt Exynos > processors, this is an problem definitely. > > #ifdef __arm__ > #define KVBASE_MASK (0xffff) > #define KVBASE (SYMBOL(_stext) & ~KVBASE_MASK) > #define _SECTION_SIZE_BITS (28) > #define _MAX_PHYSMEM_BITS (32) > > I think it's better to fix the descriptions to get acceptability, > but this patch is necessary from the view point of makedumpfile. > So I recommend you to repost this patch set, then I'll accept it. > Ok, Thanks for you suggest. I will repost this patch. By now no one relpy my kernel patch related to this issue, named "[RFC PATCH 1/2] kdump: add sparse memory related values to vmcore". Didn't I cc the right person or something else? BTW, For patch "[PATCH] makedumpfile: ARM: get correct mem_map offset", Did I explain my idea clearly ? If not, I would like repost one with more details. Thanks, Liu Hua > > Thanks > Atsushi Kumagai > >>> >>>> This patch makes makedumpfile get these two values from >>>> vmcore info, if existing. It makes the makedumpfile more >>>> compatible to vmcores with different section size. >>>> >>>> Signed-off-by: Liu Hua <sdu.liu@huawei.com> >>>> --- >>>> makedumpfile.c | 17 +++++++++++++++++ >>>> makedumpfile.h | 2 ++ >>>> 2 files changed, 19 insertions(+) >>>> >>>> diff --git a/makedumpfile.c b/makedumpfile.c >>>> index 6cf6e24..3cdf323 100644 >>>> --- a/makedumpfile.c >>>> +++ b/makedumpfile.c >>>> @@ -2111,6 +2111,8 @@ read_vmcoreinfo(void) >>>> READ_NUMBER("PG_slab", PG_slab); >>>> READ_NUMBER("PG_buddy", PG_buddy); >>>> READ_NUMBER("PG_hwpoison", PG_hwpoison); >>>> + READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS); >>>> + READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS); >>>> >>>> READ_SRCFILE("pud_t", pud_t); >>>> >>>> @@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void) >>>> } >>>> >>>> int >>>> +calibrate_machdep_info(void) >>>> +{ >>>> + if (NUMBER(MAX_PHYSMEM_BITS) > 0) >>>> + info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS); >>>> + >>>> + if (NUMBER(SECTION_SIZE_BITS) > 0) >>>> + info->section_size_bits = NUMBER(SECTION_SIZE_BITS); >>>> + >>>> + return TRUE; >>>> +} >>>> + >>>> +int >>>> initial(void) >>>> { >>>> off_t offset; >>>> @@ -3214,6 +3228,9 @@ out: >>>> if (debug_info && !get_machdep_info()) >>>> return FALSE; >>>> >>>> + if (debug_info && !calibrate_machdep_info()) >>>> + return FALSE; >>>> + >>>> if (is_xen_memory() && !get_dom0_mapnr()) >>>> return FALSE; >>>> >>>> diff --git a/makedumpfile.h b/makedumpfile.h >>>> index eb03688..7acb23a 100644 >>>> --- a/makedumpfile.h >>>> +++ b/makedumpfile.h >>>> @@ -1434,6 +1434,8 @@ struct number_table { >>>> long PG_hwpoison; >>>> >>>> long PAGE_BUDDY_MAPCOUNT_VALUE; >>>> + long SECTION_SIZE_BITS; >>>> + long MAX_PHYSMEM_BITS; >>>> }; >>>> >>>> struct srcfile_table { >>>> -- >>>> 1.9.0 >>> >>> . >>> >> _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore @ 2014-05-14 12:33 ` Liu hua 0 siblings, 0 replies; 16+ messages in thread From: Liu hua @ 2014-05-14 12:33 UTC (permalink / raw) To: Atsushi Kumagai, linux@arm.linux.org.uk Cc: will.deacon@arm.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, wangnan0@huawei.com, peifeiyue@huawei.com, liusdu@126.com 于 2014/5/14 15:53, Atsushi Kumagai 写道: >> On 2014/5/13 14:21, Atsushi Kumagai wrote: >>> Hello Liu, >>> >>>> Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as >>>> macros. So if we deal with vmcores with different values >>>> of these two macros. We have to recompile makedumpfile. >>> >>> There are other macros which have architecture-specific values >>> (e.g. __PAGE_OFFSET), and some functions are specific to each >>> architecture (e.g. vaddr_to_paddr()), so we need recompilation >>> eventually. >>> >>> OTOH, we already don't need recompilation for the same architecture >>> since the values of such macros are defined for each kernel version >>> like below: >>> >>> #ifdef __x86_64__ >>> ... >>> #define _MAX_PHYSMEM_BITS_ORIG (40) >>> #define _MAX_PHYSMEM_BITS_2_6_26 (44) >>> #define _MAX_PHYSMEM_BITS_2_6_31 (46) >>> >>> So I don't think this patch is valuable. >> >> Hi Atsushi, >> >> For x86, it is not necessory. But for arm, different venders >> may define different SECTION_SIZE_BITS. for example: >> >> 1 arch/arm/mach-clps711x/include/mach/memory.h >> #define SECTION_SIZE_BITS 24 >> 2 arch/arm/mach-exynos/include/mach/memory.h >> #define SECTION_SIZE_BITS 28 >> 4 arch/arm/mach-hisi/include/mach/memory.h >> #define SECTION_SIZE_BITS 26 >> 8 arch/arm/mach-sa1100/include/mach/memory.h >> #define SECTION_SIZE_BITS 27 >> >> Perhaps we should find another way to let the userspace tools >> to get the architecture-specific values. > > I see, I think this description is better than the first one. > > Now, makedumpfile can't get an appropriate values of the two macros since the > values are variable even if the architecture and the kernel version are fixed > (at least for arm), and we can't solve this without *manual code fixing*, right? > > In practice, the current code expects that all arm machines adopt Exynos > processors, this is an problem definitely. > > #ifdef __arm__ > #define KVBASE_MASK (0xffff) > #define KVBASE (SYMBOL(_stext) & ~KVBASE_MASK) > #define _SECTION_SIZE_BITS (28) > #define _MAX_PHYSMEM_BITS (32) > > I think it's better to fix the descriptions to get acceptability, > but this patch is necessary from the view point of makedumpfile. > So I recommend you to repost this patch set, then I'll accept it. > Ok, Thanks for you suggest. I will repost this patch. By now no one relpy my kernel patch related to this issue, named "[RFC PATCH 1/2] kdump: add sparse memory related values to vmcore". Didn't I cc the right person or something else? BTW, For patch "[PATCH] makedumpfile: ARM: get correct mem_map offset", Did I explain my idea clearly ? If not, I would like repost one with more details. Thanks, Liu Hua > > Thanks > Atsushi Kumagai > >>> >>>> This patch makes makedumpfile get these two values from >>>> vmcore info, if existing. It makes the makedumpfile more >>>> compatible to vmcores with different section size. >>>> >>>> Signed-off-by: Liu Hua <sdu.liu@huawei.com> >>>> --- >>>> makedumpfile.c | 17 +++++++++++++++++ >>>> makedumpfile.h | 2 ++ >>>> 2 files changed, 19 insertions(+) >>>> >>>> diff --git a/makedumpfile.c b/makedumpfile.c >>>> index 6cf6e24..3cdf323 100644 >>>> --- a/makedumpfile.c >>>> +++ b/makedumpfile.c >>>> @@ -2111,6 +2111,8 @@ read_vmcoreinfo(void) >>>> READ_NUMBER("PG_slab", PG_slab); >>>> READ_NUMBER("PG_buddy", PG_buddy); >>>> READ_NUMBER("PG_hwpoison", PG_hwpoison); >>>> + READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS); >>>> + READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS); >>>> >>>> READ_SRCFILE("pud_t", pud_t); >>>> >>>> @@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void) >>>> } >>>> >>>> int >>>> +calibrate_machdep_info(void) >>>> +{ >>>> + if (NUMBER(MAX_PHYSMEM_BITS) > 0) >>>> + info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS); >>>> + >>>> + if (NUMBER(SECTION_SIZE_BITS) > 0) >>>> + info->section_size_bits = NUMBER(SECTION_SIZE_BITS); >>>> + >>>> + return TRUE; >>>> +} >>>> + >>>> +int >>>> initial(void) >>>> { >>>> off_t offset; >>>> @@ -3214,6 +3228,9 @@ out: >>>> if (debug_info && !get_machdep_info()) >>>> return FALSE; >>>> >>>> + if (debug_info && !calibrate_machdep_info()) >>>> + return FALSE; >>>> + >>>> if (is_xen_memory() && !get_dom0_mapnr()) >>>> return FALSE; >>>> >>>> diff --git a/makedumpfile.h b/makedumpfile.h >>>> index eb03688..7acb23a 100644 >>>> --- a/makedumpfile.h >>>> +++ b/makedumpfile.h >>>> @@ -1434,6 +1434,8 @@ struct number_table { >>>> long PG_hwpoison; >>>> >>>> long PAGE_BUDDY_MAPCOUNT_VALUE; >>>> + long SECTION_SIZE_BITS; >>>> + long MAX_PHYSMEM_BITS; >>>> }; >>>> >>>> struct srcfile_table { >>>> -- >>>> 1.9.0 >>> >>> . >>> >> ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore 2014-05-14 12:33 ` Liu hua @ 2014-05-15 2:12 ` Atsushi Kumagai -1 siblings, 0 replies; 16+ messages in thread From: Atsushi Kumagai @ 2014-05-15 2:12 UTC (permalink / raw) To: sdu.liu@huawei.com, linux@arm.linux.org.uk Cc: wangnan0@huawei.com, peifeiyue@huawei.com, will.deacon@arm.com, liusdu@126.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, ebiederm@xmission.com >>>>> Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as >>>>> macros. So if we deal with vmcores with different values >>>>> of these two macros. We have to recompile makedumpfile. >>>> >>>> There are other macros which have architecture-specific values >>>> (e.g. __PAGE_OFFSET), and some functions are specific to each >>>> architecture (e.g. vaddr_to_paddr()), so we need recompilation >>>> eventually. >>>> >>>> OTOH, we already don't need recompilation for the same architecture >>>> since the values of such macros are defined for each kernel version >>>> like below: >>>> >>>> #ifdef __x86_64__ >>>> ... >>>> #define _MAX_PHYSMEM_BITS_ORIG (40) >>>> #define _MAX_PHYSMEM_BITS_2_6_26 (44) >>>> #define _MAX_PHYSMEM_BITS_2_6_31 (46) >>>> >>>> So I don't think this patch is valuable. >>> >>> Hi Atsushi, >>> >>> For x86, it is not necessory. But for arm, different venders >>> may define different SECTION_SIZE_BITS. for example: >>> >>> 1 arch/arm/mach-clps711x/include/mach/memory.h >>> #define SECTION_SIZE_BITS 24 >>> 2 arch/arm/mach-exynos/include/mach/memory.h >>> #define SECTION_SIZE_BITS 28 >>> 4 arch/arm/mach-hisi/include/mach/memory.h >>> #define SECTION_SIZE_BITS 26 >>> 8 arch/arm/mach-sa1100/include/mach/memory.h >>> #define SECTION_SIZE_BITS 27 >>> >>> Perhaps we should find another way to let the userspace tools >>> to get the architecture-specific values. >> >> I see, I think this description is better than the first one. >> >> Now, makedumpfile can't get an appropriate values of the two macros since the >> values are variable even if the architecture and the kernel version are fixed >> (at least for arm), and we can't solve this without *manual code fixing*, right? >> >> In practice, the current code expects that all arm machines adopt Exynos >> processors, this is an problem definitely. >> >> #ifdef __arm__ >> #define KVBASE_MASK (0xffff) >> #define KVBASE (SYMBOL(_stext) & ~KVBASE_MASK) >> #define _SECTION_SIZE_BITS (28) >> #define _MAX_PHYSMEM_BITS (32) >> >> I think it's better to fix the descriptions to get acceptability, >> but this patch is necessary from the view point of makedumpfile. >> So I recommend you to repost this patch set, then I'll accept it. >> >Ok, Thanks for you suggest. I will repost this patch. By now no one >relpy my kernel patch related to this issue, named "[RFC PATCH 1/2] >kdump: add sparse memory related values to vmcore". Didn't I cc >the right person or something else? You should CC Eric Biederman (ebiederm@xmission.com) as the maintainer of kexec. The kernel side doesn't need that patch because they aren't in trouble even without it, so we had to highlight the necessity from the user space side. Now, it's clear, I hope it will be accepted. >BTW, For patch "[PATCH] makedumpfile: ARM: get correct mem_map offset", >Did I explain my idea clearly ? If not, I would like repost one with >more details. I need more explanations, I'll mention it in that thread. Thanks Atsushi Kumagai >> >> Thanks >> Atsushi Kumagai >> >>>> >>>>> This patch makes makedumpfile get these two values from >>>>> vmcore info, if existing. It makes the makedumpfile more >>>>> compatible to vmcores with different section size. >>>>> >>>>> Signed-off-by: Liu Hua <sdu.liu@huawei.com> >>>>> --- >>>>> makedumpfile.c | 17 +++++++++++++++++ >>>>> makedumpfile.h | 2 ++ >>>>> 2 files changed, 19 insertions(+) >>>>> >>>>> diff --git a/makedumpfile.c b/makedumpfile.c >>>>> index 6cf6e24..3cdf323 100644 >>>>> --- a/makedumpfile.c >>>>> +++ b/makedumpfile.c >>>>> @@ -2111,6 +2111,8 @@ read_vmcoreinfo(void) >>>>> READ_NUMBER("PG_slab", PG_slab); >>>>> READ_NUMBER("PG_buddy", PG_buddy); >>>>> READ_NUMBER("PG_hwpoison", PG_hwpoison); >>>>> + READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS); >>>>> + READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS); >>>>> >>>>> READ_SRCFILE("pud_t", pud_t); >>>>> >>>>> @@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void) >>>>> } >>>>> >>>>> int >>>>> +calibrate_machdep_info(void) >>>>> +{ >>>>> + if (NUMBER(MAX_PHYSMEM_BITS) > 0) >>>>> + info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS); >>>>> + >>>>> + if (NUMBER(SECTION_SIZE_BITS) > 0) >>>>> + info->section_size_bits = NUMBER(SECTION_SIZE_BITS); >>>>> + >>>>> + return TRUE; >>>>> +} >>>>> + >>>>> +int >>>>> initial(void) >>>>> { >>>>> off_t offset; >>>>> @@ -3214,6 +3228,9 @@ out: >>>>> if (debug_info && !get_machdep_info()) >>>>> return FALSE; >>>>> >>>>> + if (debug_info && !calibrate_machdep_info()) >>>>> + return FALSE; >>>>> + >>>>> if (is_xen_memory() && !get_dom0_mapnr()) >>>>> return FALSE; >>>>> >>>>> diff --git a/makedumpfile.h b/makedumpfile.h >>>>> index eb03688..7acb23a 100644 >>>>> --- a/makedumpfile.h >>>>> +++ b/makedumpfile.h >>>>> @@ -1434,6 +1434,8 @@ struct number_table { >>>>> long PG_hwpoison; >>>>> >>>>> long PAGE_BUDDY_MAPCOUNT_VALUE; >>>>> + long SECTION_SIZE_BITS; >>>>> + long MAX_PHYSMEM_BITS; >>>>> }; >>>>> >>>>> struct srcfile_table { >>>>> -- >>>>> 1.9.0 >>>> >>>> . >>>> >>> > > > >_______________________________________________ >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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore @ 2014-05-15 2:12 ` Atsushi Kumagai 0 siblings, 0 replies; 16+ messages in thread From: Atsushi Kumagai @ 2014-05-15 2:12 UTC (permalink / raw) To: sdu.liu@huawei.com, linux@arm.linux.org.uk Cc: will.deacon@arm.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, wangnan0@huawei.com, peifeiyue@huawei.com, liusdu@126.com, ebiederm@xmission.com [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 5415 bytes --] >>>>> Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as >>>>> macros. So if we deal with vmcores with different values >>>>> of these two macros. We have to recompile makedumpfile. >>>> >>>> There are other macros which have architecture-specific values >>>> (e.g. __PAGE_OFFSET), and some functions are specific to each >>>> architecture (e.g. vaddr_to_paddr()), so we need recompilation >>>> eventually. >>>> >>>> OTOH, we already don't need recompilation for the same architecture >>>> since the values of such macros are defined for each kernel version >>>> like below: >>>> >>>> #ifdef __x86_64__ >>>> ... >>>> #define _MAX_PHYSMEM_BITS_ORIG (40) >>>> #define _MAX_PHYSMEM_BITS_2_6_26 (44) >>>> #define _MAX_PHYSMEM_BITS_2_6_31 (46) >>>> >>>> So I don't think this patch is valuable. >>> >>> Hi Atsushi, >>> >>> For x86, it is not necessory. But for arm, different venders >>> may define different SECTION_SIZE_BITS. for example: >>> >>> 1 arch/arm/mach-clps711x/include/mach/memory.h >>> #define SECTION_SIZE_BITS 24 >>> 2 arch/arm/mach-exynos/include/mach/memory.h >>> #define SECTION_SIZE_BITS 28 >>> 4 arch/arm/mach-hisi/include/mach/memory.h >>> #define SECTION_SIZE_BITS 26 >>> 8 arch/arm/mach-sa1100/include/mach/memory.h >>> #define SECTION_SIZE_BITS 27 >>> >>> Perhaps we should find another way to let the userspace tools >>> to get the architecture-specific values. >> >> I see, I think this description is better than the first one. >> >> Now, makedumpfile can't get an appropriate values of the two macros since the >> values are variable even if the architecture and the kernel version are fixed >> (at least for arm), and we can't solve this without *manual code fixing*, right? >> >> In practice, the current code expects that all arm machines adopt Exynos >> processors, this is an problem definitely. >> >> #ifdef __arm__ >> #define KVBASE_MASK (0xffff) >> #define KVBASE (SYMBOL(_stext) & ~KVBASE_MASK) >> #define _SECTION_SIZE_BITS (28) >> #define _MAX_PHYSMEM_BITS (32) >> >> I think it's better to fix the descriptions to get acceptability, >> but this patch is necessary from the view point of makedumpfile. >> So I recommend you to repost this patch set, then I'll accept it. >> >Ok, Thanks for you suggest. I will repost this patch. By now no one >relpy my kernel patch related to this issue, named "[RFC PATCH 1/2] >kdump: add sparse memory related values to vmcore". Didn't I cc >the right person or something else? You should CC Eric Biederman (ebiederm@xmission.com) as the maintainer of kexec. The kernel side doesn't need that patch because they aren't in trouble even without it, so we had to highlight the necessity from the user space side. Now, it's clear, I hope it will be accepted. >BTW, For patch "[PATCH] makedumpfile: ARM: get correct mem_map offset", >Did I explain my idea clearly ? If not, I would like repost one with >more details. I need more explanations, I'll mention it in that thread. Thanks Atsushi Kumagai >> >> Thanks >> Atsushi Kumagai >> >>>> >>>>> This patch makes makedumpfile get these two values from >>>>> vmcore info, if existing. It makes the makedumpfile more >>>>> compatible to vmcores with different section size. >>>>> >>>>> Signed-off-by: Liu Hua <sdu.liu@huawei.com> >>>>> --- >>>>> makedumpfile.c | 17 +++++++++++++++++ >>>>> makedumpfile.h | 2 ++ >>>>> 2 files changed, 19 insertions(+) >>>>> >>>>> diff --git a/makedumpfile.c b/makedumpfile.c >>>>> index 6cf6e24..3cdf323 100644 >>>>> --- a/makedumpfile.c >>>>> +++ b/makedumpfile.c >>>>> @@ -2111,6 +2111,8 @@ read_vmcoreinfo(void) >>>>> READ_NUMBER("PG_slab", PG_slab); >>>>> READ_NUMBER("PG_buddy", PG_buddy); >>>>> READ_NUMBER("PG_hwpoison", PG_hwpoison); >>>>> + READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS); >>>>> + READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS); >>>>> >>>>> READ_SRCFILE("pud_t", pud_t); >>>>> >>>>> @@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void) >>>>> } >>>>> >>>>> int >>>>> +calibrate_machdep_info(void) >>>>> +{ >>>>> + if (NUMBER(MAX_PHYSMEM_BITS) > 0) >>>>> + info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS); >>>>> + >>>>> + if (NUMBER(SECTION_SIZE_BITS) > 0) >>>>> + info->section_size_bits = NUMBER(SECTION_SIZE_BITS); >>>>> + >>>>> + return TRUE; >>>>> +} >>>>> + >>>>> +int >>>>> initial(void) >>>>> { >>>>> off_t offset; >>>>> @@ -3214,6 +3228,9 @@ out: >>>>> if (debug_info && !get_machdep_info()) >>>>> return FALSE; >>>>> >>>>> + if (debug_info && !calibrate_machdep_info()) >>>>> + return FALSE; >>>>> + >>>>> if (is_xen_memory() && !get_dom0_mapnr()) >>>>> return FALSE; >>>>> >>>>> diff --git a/makedumpfile.h b/makedumpfile.h >>>>> index eb03688..7acb23a 100644 >>>>> --- a/makedumpfile.h >>>>> +++ b/makedumpfile.h >>>>> @@ -1434,6 +1434,8 @@ struct number_table { >>>>> long PG_hwpoison; >>>>> >>>>> long PAGE_BUDDY_MAPCOUNT_VALUE; >>>>> + long SECTION_SIZE_BITS; >>>>> + long MAX_PHYSMEM_BITS; >>>>> }; >>>>> >>>>> struct srcfile_table { >>>>> -- >>>>> 1.9.0 >>>> >>>> . >>>> >>> > > > >_______________________________________________ >kexec mailing list >kexec@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/kexec ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2014-05-15 2:14 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-05-07 13:27 [RFC PATCH 0/2] transfer sparse memory related values Liu Hua 2014-05-07 13:27 ` Liu Hua 2014-05-07 13:27 ` [RFC PATCH 1/2] kdump: add sparse memory related values to vmcore Liu Hua 2014-05-07 13:27 ` Liu Hua 2014-05-07 13:27 ` [RFC PATCH 2/2] makedumpfile: get additional information from vmcore Liu Hua 2014-05-07 13:27 ` Liu Hua 2014-05-13 6:21 ` Atsushi Kumagai 2014-05-13 6:21 ` Atsushi Kumagai 2014-05-13 7:25 ` Liu hua 2014-05-13 7:25 ` Liu hua 2014-05-14 7:53 ` Atsushi Kumagai 2014-05-14 7:53 ` Atsushi Kumagai 2014-05-14 12:33 ` Liu hua 2014-05-14 12:33 ` Liu hua 2014-05-15 2:12 ` Atsushi Kumagai 2014-05-15 2:12 ` Atsushi Kumagai
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.