Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sgoel@codeaurora.org
To: Pratyush Anand <panand@redhat.com>
Cc: Timur Tabi <timur@codeaurora.org>,
	Azriel Samson <asamson@codeaurora.org>,
	kexec@lists.infradead.org, sgoel@codeaurora.org,
	virajm@codeaurora.org, ats-kumagai@wm.jp.nec.com
Subject: Re: [PATCH] makedumpfile: Support ARM64
Date: Mon, 24 Aug 2015 18:17:03 -0000	[thread overview]
Message-ID: <5053347ed9f8e4e245d8438b3a8c981d.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <20150822035445.GC3013@dhcppc13.redhat.com>

> * 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@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
>



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2015-08-24 18:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-15 18:30 [PATCH] makedumpfile: Support ARM64 Pratyush Anand
2015-05-19  7:26 ` Atsushi Kumagai
2015-06-23 23:19 ` Timur Tabi
2015-06-24  3:32   ` Pratyush Anand
2015-06-24  3:36     ` Timur Tabi
2015-06-27  8:22       ` Pratyush Anand
2015-07-01 18:42         ` Azriel Samson
2015-07-03  4:32           ` Pratyush Anand
2015-07-08 23:03             ` Azriel Samson
2015-08-18 17:18               ` Azriel Samson
2015-08-19 23:16                 ` sgoel
2015-08-20 11:21                   ` Pratyush Anand
2015-08-20 16:11                     ` sgoel
2015-08-21  3:44                       ` Pratyush Anand
2015-08-21  7:25                         ` Atsushi Kumagai
2015-08-21 20:37                         ` sgoel
2015-08-22  3:54                           ` Pratyush Anand
2015-08-24 18:17                             ` sgoel [this message]
2015-08-25  0:21                               ` sgoel
2015-09-08 22:32                                 ` sgoel
2015-09-11 16:52                                   ` Pratyush Anand
2015-09-14 16:02                                     ` sgoel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5053347ed9f8e4e245d8438b3a8c981d.squirrel@www.codeaurora.org \
    --to=sgoel@codeaurora.org \
    --cc=asamson@codeaurora.org \
    --cc=ats-kumagai@wm.jp.nec.com \
    --cc=kexec@lists.infradead.org \
    --cc=panand@redhat.com \
    --cc=timur@codeaurora.org \
    --cc=virajm@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox