Hi Pratush, I added the mappings for PMD translations to the vtop function. This helped in translating the address to physical. Issues seen: 1. If PMD translates to a section. The physical translations does not get rid of the PMD flags. So, the physical address shows up as invalid and code crashes when it tries to read this address from ELF. 2. After treating this as a PTE table address, we see a compression of around 50%. But the final file generated not does not load using the crash tool. Any recommendations will be helpful. Thanks, Sameer > 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 >>> >> >> >> > > >
