[PATCH] makedumpfile: Support ARM64

[sgoel at codeaurora.org]

I also looked at the definitions for PMD_OFFSET in the code and this is
evaluating to no PMD. This should not be the case. So, I am wondering if
these defines should change?

I tried changing these but still the virtual address to physical address
translation is failing.

Please comment.
Thanks,
Sameer



>> * You did following changes on top of
>> https://github.com/pratyushanand/makedumpfile.git:arm64_support (last
>> commit
>> 597ea74d40b7 arm64: Fix KVBASE) and it worked for you, right?
>
> Yes. Making the change to kernel struct page size fixed the memory map
> values. We are using a 4.0.0 kernel. I checked the struct page and there
> are some changes to it between the kernel versions. There is no platform
> specific change that we have made.
>
> The code still cannot find the free pages as it is exiting due to a
> virtual to physical translation.
> readmem: Can't convert a virtual address(ffffffbee0023000) to physical
> address.
> readmem: type_addr: 0, addr:ffffffbee0023000, size:28672
> __exclude_unnecessary_pages: Can't read the buffer of struct page.
> create_2nd_bitmap: Can't exclude unnecessary pages.
>
> The above is a valid virtual address and maps to a correct physical
> address when I check this using kmem -p using the crash tool. Any help
> will be appreciated.
>
> Thanks,
> Sameer
>
>
>
>> On 21/08/2015:08:37:57 PM, sgoel at codeaurora.org wrote:
>>> > Can you compare "Virtual kernel memory layout:" print of Linux kernel
>>> boot
>>> > with
>>> > makedumpfile print for page_offset, vmalloc_start, vmemmap_start etc,
>>> and
>>> > see if
>>> > they match?
>>> >
>>> > They should match.
>>>
>>>
>>> Yes this was a problem. The assumed Kernel struct page size in the tool
>>> is
>>> 64. For our platform this evaluates to 56. After changing this value
>>> all
>>> the memory mapping values match.
>>
>> Great !!!
>>
>> To be on the same page:
>> * You did following changes on top of
>> https://github.com/pratyushanand/makedumpfile.git:arm64_support (last
>> commit
>> 597ea74d40b7 arm64: Fix KVBASE) and it worked for you, right? If yes,
>> then
>> is
>> there out of mainline change in struct page for you? If it is mainline,
>> then can
>> you please let me know the kernel version, so that on the basic of
>> kernel
>> version I can fix it.
>>
>> diff --git a/arch/arm64.c b/arch/arm64.c
>> index a94a4ba16dd5..4154ed6fe4a5 100644
>> --- a/arch/arm64.c
>> +++ b/arch/arm64.c
>> @@ -86,7 +86,7 @@ typedef struct {
>>  /* kernel struct page size can be kernel version dependent, currently
>>   * keep it constant.
>>   */
>> -#define KERN_STRUCT_PAGE_SIZE		64
>> +#define KERN_STRUCT_PAGE_SIZE		56
>>  #define ALIGN(x, a) 			(((x) + (a) - 1) & ~((a) - 1))
>>  #define PFN_DOWN(x)			((x) >> PAGE_SHIFT)
>>  #define VMEMMAP_SIZE			ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) *
>> KERN_STRUCT_PAGE_SIZE, PUD_SIZE)
>>
>>>
>>> I wanted to ask if the page table translation function would be any
>>> different if the page size is 4k instead of 64k?
>>
>> I believe, if we have programmed pgtable_level, va_bits and page_shift
>> correctly, then vtop_arm64 should be able to calculate it for both 4K
>> and
>> 64K.
>>
>> ~Pratyush
>>
>
>
>