From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Geoff Levand <geoff@infradead.org>
Cc: Pratyush Anand <panand@redhat.com>,
kexec@lists.infradead.org, Baoquan He <bhe@redhat.com>
Subject: Re: [PATCH RFC 3/6] arm64: allocate memory for other segments after kernel
Date: Wed, 22 Apr 2015 15:16:47 +0900 [thread overview]
Message-ID: <55373CCF.3030101@linaro.org> (raw)
In-Reply-To: <5536211E.9040704@linaro.org>
Geoff,
On 04/21/2015 07:06 PM, AKASHI Takahiro wrote:
> Prayush,
> Cc: Geoff
>
> Please add me to Cc if you intend to modify my part of kexec-tools since I don't
> subscribe kexec ML, and keep in mind that my repo on git.linaro.org is not for
> public review.
>
> On 04/21/2015 01:19 PM, Pratyush Anand wrote:
>>
>>
>> On Monday 20 April 2015 08:51 AM, Baoquan He wrote:
>>> On 04/16/15 at 10:17pm, Pratyush Anand wrote:
>>>> In case of KEXEC_ON_CRASH, load other segments after the addresses where
>>>> kernel segments finish.
>>>>
>>>> Signed-off-by: Pratyush Anand <panand@redhat.com>
>>>> ---
>>>> kexec/arch/arm64/crashdump-arm64.c | 3 ++-
>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/kexec/arch/arm64/crashdump-arm64.c b/kexec/arch/arm64/crashdump-arm64.c
>>>> index 41266f294589..75f4e4d269ca 100644
>>>> --- a/kexec/arch/arm64/crashdump-arm64.c
>>>> +++ b/kexec/arch/arm64/crashdump-arm64.c
>>>> @@ -312,5 +312,6 @@ void set_crash_entry(struct mem_ehdr *ehdr, struct kexec_info *info)
>>>> off_t locate_dtb_in_crashmem(struct kexec_info *info, off_t dtb_size)
>>>> {
>>>> return locate_hole(info, dtb_size, 128UL * 1024,
>>>> - crash_reserved_mem.start, crash_reserved_mem.end, 1);
>>>> + crash_reserved_mem.start + arm64_mem.text_offset +
>>>> + arm64_mem.image_size, crash_reserved_mem.end, 1);
>>>
>>> So you have decided to hard code the sequence of segment. It
>>> seems not good. Why don't do it by calling add_buffer_phys_virt() or
>>> implement a similar function if you don't like add_buffer_phys_virt.
>>
>> I agree that code is a bit tightly coupled here. I think, Takahiro can comment better.
>
> The *hard-coded* segments order is attributed to Geoff's original code.
>
>> arm64 does use add_buffer_phys_virt to add all the buffers into segment list. arm64_load_other_segments function adds
>> buffers for all segments other than kernel and elfcorehdr. This function calls add_buffer_phys_virt to load different
>> segments like dtb, initrd and purgatory. Only limitation we are putting that we find free area for all these segments
>> after the area where kernel finishes. Currently load sequence is like dtb, initrd and then purgatory. But I believe,
>> even if we use other load sequence in arm64_load_other_segments, it should work.
>
> I think that add_buffer_phys_virt() should be used instead of locate_hole() to remove
> this enforced ordering because locate_hole() assumes that segments in struct info
> be sorted properly.
> I'm trying the following hack: (pls ignore #if's)
If you agree, please think of taking my patch (the last commit) in v0.12 in my repo.
(I tested the code in case of kexec as well as kdump with 4MB initrd.)
-Takahiro AKASHI
> diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
> index 2c5238c..642c4a9 100644
> --- a/kexec/arch/arm64/kexec-arm64.c
> +++ b/kexec/arch/arm64/kexec-arm64.c
> @@ -583,6 +583,7 @@ int arm64_load_other_segments(struct kexec_info *info,
> struct mem_ehdr ehdr;
> unsigned long dtb_max;
> unsigned long dtb_base;
> + unsigned long hole_min, hole_max;
> char *initrd_buf = NULL;
> uint64_t purgatory_sink;
> unsigned long purgatory_base;
> @@ -639,17 +640,28 @@ int arm64_load_other_segments(struct kexec_info *info,
> * to the DTB size for any DTB growth.
> */
>
> - dtb_max = dtb_2.size + 2 * 1024;
> + if (info->kexec_flags & KEXEC_ON_CRASH) {
> +#if 1
> + hole_min = crash_reserved_mem.start;
> +#else
> + hole_min = crash_reserved_mem.start + arm64_mem.text_offset
> + + arm64_mem.image_size;
> +#endif
> + hole_max = crash_reserved_mem.end;
> + } else {
> + hole_min = arm64_mem.memstart + arm64_mem.text_offset
> + + arm64_mem.image_size;
> + hole_max = ULONG_MAX;
> + }
>
> - if (info->kexec_flags & KEXEC_ON_CRASH)
> - dtb_base = locate_dtb_in_crashmem(info, dtb_max);
> - else
> - dtb_base = locate_hole(info, dtb_max, 128UL * 1024,
> - arm64_mem.memstart + arm64_mem.text_offset
> - + arm64_mem.image_size,
> - _ALIGN_UP(arm64_mem.memstart + arm64_mem.text_offset,
> - 512UL * 1024 * 1024),
> - 1);
> + dtb_max = dtb_2.size + 2 * 1024;
> +#if 1
> + dtb_base = add_buffer_phys_virt(info, dtb_2.buf, dtb_2.size, dtb_max,
> + 128UL * 1024, hole_min, hole_max, 1, 0);
> +#else
> + dtb_base = locate_hole(info, dtb_max, 128UL * 1024,
> + hole_min, hole_max, 1);
> +#endif
> dbgprintf("dtb: base %lx, size %lxh (%ld)\n", dtb_base, dtb_2.size,
> dtb_2.size);
> @@ -670,8 +686,14 @@ int arm64_load_other_segments(struct kexec_info *info,
> /* Put the initrd after the DTB with an alignment of
> * page size. */
>
> +#if 1
> + initrd_base = add_buffer_phys_virt(info, initrd_buf,
> + initrd_size, initrd_size, 0,
> + hole_min, hole_max, 1, 0);
> +#else
> initrd_base = locate_hole(info, initrd_size, 0,
> - dtb_base + dtb_max, -1, 1);
> + dtb_base + dtb_max, hole_max, 1);
> +#endif
>
> dbgprintf("initrd: base %lx, size %lxh (%ld)\n",
> initrd_base, initrd_size, initrd_size);
> @@ -695,12 +717,14 @@ int arm64_load_other_segments(struct kexec_info *info,
> return -EINVAL;
> }
>
> +#if 0
> add_segment_phys_virt(info, dtb_2.buf, dtb_2.size, dtb_base,
> dtb_2.size, 0);
>
> if (arm64_opts.initrd)
> add_segment_phys_virt(info, initrd_buf, initrd_size,
> initrd_base, initrd_size, 0);
> +#endif
>
> if (arm64_opts.lite)
> info->entry = (void *)kernel_entry;
> @@ -714,8 +738,13 @@ int arm64_load_other_segments(struct kexec_info *info,
> return -EBADF;
> }
>
> +#if 1
> + elf_rel_build_load(info, &info->rhdr, purgatory, purgatory_size,
> + hole_min, hole_max, 1, 0);
> +#else
> elf_rel_build_load(info, &info->rhdr, purgatory, purgatory_size,
> - purgatory_base, ULONG_MAX, 1, 0);
> + purgatory_base, hole_max, 1, 0);
> +#endif
>
> info->entry = (void *)elf_rel_get_addr(&info->rhdr,
> "purgatory_start");
>
> Thanks,
> -Takahiro AKASHI
>
>>
>> Not sure, if understood the question and replied well.
>>
>> ~Pratyush
>>
>>
>>
>>>
>>>> }
>>>> --
>>>> 2.1.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
>>>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2015-04-22 6:17 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-16 16:47 [PATCH RFC 0/6] Various fixes for purgatory and ARM64 Pratyush Anand
2015-04-16 16:47 ` [PATCH RFC 1/6] purgatory: Fix memcmp for src address increment Pratyush Anand
2015-04-17 16:55 ` Geoff Levand
2015-04-20 0:25 ` Simon Horman
2015-04-22 11:19 ` Pratyush Anand
2015-04-23 2:23 ` Simon Horman
2015-04-16 16:47 ` [PATCH RFC 2/6] purgatory: No need to sha256 update if ptr->len is zero Pratyush Anand
2015-04-17 16:58 ` Geoff Levand
2015-04-17 23:26 ` Pratyush Anand
2015-04-20 3:01 ` Baoquan He
2015-04-20 3:18 ` Pratyush Anand
2015-04-16 16:47 ` [PATCH RFC 3/6] arm64: allocate memory for other segments after kernel Pratyush Anand
2015-04-17 16:59 ` Geoff Levand
2015-04-20 3:21 ` Baoquan He
2015-04-21 4:19 ` Pratyush Anand
2015-04-21 10:06 ` AKASHI Takahiro
2015-04-22 6:16 ` AKASHI Takahiro [this message]
2015-04-16 16:47 ` [PATCH RFC 4/6] arm64: support reuse-cmdline option Pratyush Anand
2015-04-17 17:02 ` Geoff Levand
2015-04-16 16:47 ` [PATCH RFC 5/6] arm64: Add support for binary image Pratyush Anand
2015-04-17 17:07 ` Geoff Levand
2015-04-17 18:00 ` Geoff Levand
2015-04-17 23:27 ` Pratyush Anand
2015-04-20 7:24 ` Baoquan He
2015-04-21 4:42 ` Pratyush Anand
2015-04-22 2:53 ` Baoquan He
2015-04-22 11:19 ` Pratyush Anand
2015-04-16 16:47 ` [PATCH RFC 6/6] arm64: wait for transmit completion before next character transmission Pratyush Anand
2015-04-17 5:36 ` Minfei Huang
2015-04-17 5:37 ` Pratyush Anand
2015-04-20 2:58 ` Baoquan He
2015-04-20 3:34 ` Pratyush Anand
2015-04-17 17:22 ` Geoff Levand
2015-04-17 23:31 ` Pratyush Anand
2015-04-16 23:54 ` [PATCH RFC 0/6] Various fixes for purgatory and ARM64 Simon Horman
2015-04-17 1:27 ` Dave Young
2015-04-17 2:48 ` Pratyush Anand
2015-04-17 17:27 ` Geoff Levand
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=55373CCF.3030101@linaro.org \
--to=takahiro.akashi@linaro.org \
--cc=bhe@redhat.com \
--cc=geoff@infradead.org \
--cc=kexec@lists.infradead.org \
--cc=panand@redhat.com \
/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