From: Paul Mackerras <paulus@samba.org>
To: mohan@in.ibm.com
Cc: ppcdev <linuxppc-dev@ozlabs.org>, kexec@lists.infradead.org
Subject: Re: [PATCH] Support for relocatable kdump kernel
Date: Thu, 9 Oct 2008 16:27:08 +1100 [thread overview]
Message-ID: <18669.38444.112286.785452@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <20081001182645.GB20319@in.ibm.com>
Mohan Kumar M writes:
> Support for relocatable kdump kernel
[snip]
> @@ -1384,7 +1392,15 @@ _STATIC(__after_prom_start)
> /* process relocations for the final address of the kernel */
> lis r25,PAGE_OFFSET@highest /* compute virtual base of kernel */
> sldi r25,r25,32
> - mr r3,r25
> +#ifdef CONFIG_CRASH_DUMP
> + ld r7,__kdump_flag@got(r2)
> + add r7,r7,r26
> + ld r7,0(r7)
I think it is dangerous to use an address from the GOT at this point
when we haven't called relocate() yet. In fact those 3 instructions
can be replaced by one:
ld r7,__kdump_flag-_stext(r26)
since we have our base address (i.e. the address of _stext) in r26 at
this point.
> +#ifdef CONFIG_RELOCATABLE
> +#ifdef CONFIG_CRASH_DUMP
> +/*
> + * Check if the kernel has to be running as relocatable kernel based on the
> + * variable __kdump_flag, if it is set the kernel is treated as relocatble
> + * kernel, otherwise it will be moved to PHYSICAL_START
> + */
> + ld r7,__kdump_flag@got(r2)
> + ld r7,0(r7)
Here again I would rather you did
ld r7,__kdump_flag-_stext(r26)
since the kernel is relocated for its final location by this point,
but it is not running at the final location yet.
> + cmpldi cr0,r7,1
> + bne regular
> +
> + li r5,__end_interrupts - _stext /* just copy interrupts */
> + b 5f
> +regular:
> +#endif
> + lis r5,(copy_to_here - _stext)@ha
> + addi r5,r5,(copy_to_here - _stext)@l /* # bytes of memory to copy */
>
> bl .copy_and_flush /* copy the first n bytes */
> /* this includes the code being */
> @@ -1411,15 +1443,33 @@ _STATIC(__after_prom_start)
> mtctr r8
> bctr
>
> +p_end: .llong _end - _stext
> +
> 4: /* Now copy the rest of the kernel up to _end */
> addis r5,r26,(p_end - _stext)@ha
> ld r5,(p_end - _stext)@l(r5) /* get _end */
> - bl .copy_and_flush /* copy the rest */
> +#else
> + lis r5,(copy_to_here - _stext)@ha
> + addi r5,r5,(copy_to_here - _stext)@l /* # bytes of memory to copy */
>
> -9: b .start_here_multiplatform
> + bl .copy_and_flush /* copy the first n bytes */
> + /* this includes the code being */
> + /* executed here. */
> + addis r8,r3,(4f - _stext)@ha /* Jump to the copy of this code */
> + addi r8,r8,(4f - _stext)@l /* that we just made */
> + mtctr r8
> + bctr
>
> p_end: .llong _end - _stext
>
> +4: /* Now copy the rest of the kernel up to _end */
> + addis r5,r26,(p_end - _stext)@ha
> + ld r5,(p_end - _stext)@l(r5) /* get _end */
> +#endif
> +5: bl .copy_and_flush /* copy the rest */
> +
> +9: b .start_here_multiplatform
You have ended up with two separate copies of the code here depending
on whether or not we have CONFIG_RELOCATABLE set. I don't think the
code paths should be different to such an extent. Please try to make
the ifdef as small as possible (ideally, nonexistent).
Paul.
next prev parent reply other threads:[~2008-10-09 5:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-01 18:26 [PATCH] Support for relocatable kdump kernel Mohan Kumar M
2008-10-09 5:27 ` Paul Mackerras [this message]
2008-10-09 16:35 ` Mohan Kumar M
-- strict thread matches above, loose matches on Subject: below --
2008-10-12 23:34 Mohan Kumar M
2008-10-13 1:30 ` Paul Mackerras
2008-10-16 10:33 ` Mohan Kumar M
[not found] <18684.5062.154465.668614@drongo.ozlabs.ibm.com>
2008-10-20 6:43 ` Michael Ellerman
2008-10-20 9:34 ` Mohan Kumar M
2008-10-21 6:03 ` Michael Ellerman
2008-10-21 18:21 ` Mohan Kumar M
2008-10-22 3:38 Michael Ellerman
2008-10-22 4:56 Milton Miller
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=18669.38444.112286.785452@cargo.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=kexec@lists.infradead.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mohan@in.ibm.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;
as well as URLs for NNTP newsgroup(s).