[RFC PATCH 0/2] transfer sparse memory related values

[RFC PATCH 0/2] transfer sparse memory related values

[Liu Hua]

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

[RFC PATCH 1/2] kdump: add sparse memory related values to vmcore

[Liu Hua]

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

[RFC PATCH 2/2] makedumpfile: get additional information from vmcore

[Liu Hua]

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

RE: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore

[Atsushi Kumagai]

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

Re: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore

[Liu hua]

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

RE: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore

[Atsushi Kumagai]

[-- 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¥

Re: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore

[Liu hua]

于 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
>>>
>>> .
>>>
>>

RE: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore

[Atsushi Kumagai]

[-- 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¥