From: Mohan Kumar M <mohan@in.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: ppcdev <linuxppc-dev@ozlabs.org>, kexec@lists.infradead.org
Subject: Re: [PATCH] Support for relocatable kdump kernel
Date: Thu, 09 Oct 2008 22:05:22 +0530 [thread overview]
Message-ID: <48EE32CA.5070401@in.ibm.com> (raw)
In-Reply-To: <18669.38444.112286.785452@cargo.ozlabs.ibm.com>
Hi Paul,
Thank you for the review. I will implement the changes you suggested and
send the patches.
Regards,
Mohan.
> 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.
>
> _______________________________________________
> 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
WARNING: multiple messages have this Message-ID (diff)
From: Mohan Kumar M <mohan@in.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: ppcdev <linuxppc-dev@ozlabs.org>, kexec@lists.infradead.org
Subject: Re: [PATCH] Support for relocatable kdump kernel
Date: Thu, 09 Oct 2008 22:05:22 +0530 [thread overview]
Message-ID: <48EE32CA.5070401@in.ibm.com> (raw)
In-Reply-To: <18669.38444.112286.785452@cargo.ozlabs.ibm.com>
Hi Paul,
Thank you for the review. I will implement the changes you suggested and
send the patches.
Regards,
Mohan.
> 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.
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2008-10-09 16:35 UTC|newest]
Thread overview: 22+ 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-01 18:26 ` Mohan Kumar M
2008-10-09 5:27 ` Paul Mackerras
2008-10-09 5:27 ` Paul Mackerras
2008-10-09 16:35 ` Mohan Kumar M [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-12 23:34 ` Mohan Kumar M
2008-10-13 1:30 ` Paul Mackerras
2008-10-13 1:30 ` Paul Mackerras
2008-10-16 10:33 ` Mohan Kumar M
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 6:43 ` Michael Ellerman
2008-10-20 9:34 ` Mohan Kumar M
2008-10-20 9:34 ` Mohan Kumar M
2008-10-21 6:03 ` Michael Ellerman
2008-10-21 6:03 ` Michael Ellerman
2008-10-21 18:21 ` Mohan Kumar M
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=48EE32CA.5070401@in.ibm.com \
--to=mohan@in.ibm.com \
--cc=kexec@lists.infradead.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.