public inbox for kexec@lists.infradead.org
 help / color / mirror / Atom feed
From: Milton Miller <miltonm@bga.com>
To: Mohan Kumar M <mohan@in.ibm.com>
Cc: Ben Herrenschmidt <benh@kernel.crashing.org>,
	kexec@lists.infradead.org,
	Michael Ellerman <michael@ellerman.id.au>,
	linuxppc-dev@ozlabs.org, Simon Horman <horms@verge.net.au>,
	Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH 3/3] powerpc/ppc64/kdump: better flag for running relocatable
Date: Fri, 7 Nov 2008 07:59:26 -0600	[thread overview]
Message-ID: <b6c6e115495e149f24d2de5cb82a92ab@bga.com> (raw)
In-Reply-To: <4900952A.3090605@in.ibm.com>

On Oct 23, 2008, at 10:15 AM, Mohan Kumar M wrote:
> Hi Milton,
> My suggestions:
> Milton Miller wrote:
>> The __kdump_flag ABI is overly constraining for future development.
...
>> Now that we have eliminated the use of __kdump_flag in favor of
>> the standard is_kdump_kernel(), this flag only controls run without
>> relocating the kernel to PHYSICAL_START (0), so rename it 
>> __run_at_load.
>>
> We could try both of our approaches. Instead of passing the 
> information that next kernel should be relocatable from kexec_sequence 
> to purgatory code, we will do it from kexec-tools path (following your 
> approach). But instead of setting the __run_at_load value in the 
> purgatory code (ie at physical address 0x5c), we will set the variable 
> __run_at_load at kernel  image itself.
>
> i.e.,
> [code snip 1]
> 	lwz	r7,__run_at_load-_stext(r26)
> 	cmplwi	cr0,r7,1	/* kdump kernel ? - stay where we are */
>  	bne	1f
>  	add	r25,r25,r26
>
> 	lwz	r7,__run_at_load-_stext(r26)
> 	cmplwi	cr0,r7,1
>  	bne	3f
>
> kexec-tools
> [code snip 2]
> 	LOADADDR(6,run_at_load)
> 	ld	18,0(6)
> 	cmpd	18,1
> 	bne	skip
> 	li	7,1
> 	stw	7,92(4)		# mark __run_at_load flag at kernel
> skip:
> 	lwz	7,0(4)		# get the first instruction that we stole
> 	stw	7,0(0)		# and put it in the slave loop at 0
>  				# skip cache flush, do we care?
>
> [code snip 3]
> 	if (info->kexec_flags & KEXEC_ON_CRASH) {
> 		....
> 		elf_rel_set_symbol(&info->rhdr, "run_at_load",
>                                 &my_run_at_load, 							 
> sizeof(my_run_at_load));
> 	}


This elf_rel_set_symbol sets the copy in purgatory,
after we have copied the code from the kernel.  It
is this copy that gets copied to address 0.

However this information is not in the code that
is at the start of the kernel.  We don't have any
symbols for the kernel itself, it might be stripped.
So we can't use the elf_set_symbol api.  (The kernel
may not be relocatable either).

> Using this approach we are not breaking the kexec_sequence
> ABI and we directly modifying the flag in kernel image.
>
> Regards,
> Mohan.

I'll prepare a patch, but it might be a few days
while I catch up from my 2 week vacation.

milton


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

  reply	other threads:[~2008-11-07 13:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <f90d4d7306443a720ca31adf513faf25@bga.com>
2008-10-22 20:39 ` [PATCH 3/3] powerpc/ppc64/kdump: better flag for running relocatable Milton Miller
2008-10-23  3:23   ` Michael Neuling
2008-10-23  3:32   ` Paul Mackerras
2008-10-23  3:43     ` Paul Mackerras
2008-10-24  4:41       ` Michael Neuling
2008-11-07 13:52       ` Milton Miller
2008-10-23 15:15   ` Mohan Kumar M
2008-11-07 13:59     ` Milton Miller [this message]
2008-11-10 15:22       ` Mohan Kumar M
2008-11-11 16:06         ` Milton Miller
2008-10-22 20:39 ` [PATCH 2/2 kexec-tools] ppc64: segemments are sorted Milton Miller
2008-10-22 20:47   ` Milton Miller
2008-10-22 20:39 ` [PATCH 1/2 kexec-tools] ppc64: new relocatble kernel activation ABI Milton Miller
2008-10-22 20:39 ` [PATCH 1/3] powerpc: kexec exit should not use magic numbers Milton Miller
2008-10-22 23:18   ` Simon Horman

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=b6c6e115495e149f24d2de5cb82a92ab@bga.com \
    --to=miltonm@bga.com \
    --cc=benh@kernel.crashing.org \
    --cc=horms@verge.net.au \
    --cc=kexec@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=michael@ellerman.id.au \
    --cc=mohan@in.ibm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox