From: Michael Neuling <mikey@neuling.org>
To: Milton Miller <miltonm@bga.com>
Cc: Simon Horman <horms@verge.net.au>,
kexec@lists.infradead.org, Paul Mackerras <paulus@samba.org>,
linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 3/3] powerpc/ppc64/kdump: better flag for running relocatable
Date: Thu, 23 Oct 2008 14:23:27 +1100 [thread overview]
Message-ID: <25820.1224732207@neuling.org> (raw)
In-Reply-To: <kexec-kern-2@bga.com>
In message <kexec-kern-2@bga.com> you wrote:
> The __kdump_flag ABI is overly constraining for future development.
>
> As of 2.6.27, the kernel entry point has 4 constraints: Offset 0 is
> the starting point for the master (boot) cpu (entered with r3 pointing
> to the device tree structure), offset 0x60 is code for the slave cpus
> (entered with r3 set to their device tree physical id), offset 0x20 is
> used by the iseries hypervisor, and secondary cpus must be well behaved
> when the first 256 bytes are copied to address 0.
>
> Placing the __kdump_flag at 0x18 is bad because:
>
> - It was taking the last 8 bytes before the iseries hypervisor data.
> - It was 8 bytes for a boolean flag
> - It had no way of identifying that the flag was present
> - It does leave any room for the master to add any additional code
> before branching, which hurts debug.
> - It will be unnecessarily hard for 32 bit code to be common (8 bytes)
>
> 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.
>
> Move the flag to 0x5c, 1 word before the secondary cpu entry point at
> 0x60. Use the copy at address 0 not the one in the base kernel image to
> make it easier on kexec-tools. Initialize it with "run0" to say it will
> run at 0 unless it is set to 1. It only exists if we are relocatable.
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
> ---
> I left it global so it appears that way in System.map, but it would
> not need to be.
>
> I kept the guards with CONFIG_CRASH_DUMP for now. They could be relaxed
> to just CONFIG_RELOCATABLE.
>
> Tested with normal kexec (kernel moved to 0) and a custom boot-loader
> (kernel stayed at loaded 16MB start).
>
> Index: next.git/arch/powerpc/kernel/head_64.S
> ===================================================================
> --- next.git.orig/arch/powerpc/kernel/head_64.S 2008-10-22 04:30:08.000
000000 -0500
> +++ next.git/arch/powerpc/kernel/head_64.S 2008-10-22 04:59:55.000000000 -
0500
> @@ -97,12 +97,6 @@ __secondary_hold_spinloop:
> __secondary_hold_acknowledge:
> .llong 0x0
>
> - /* This flag is set by purgatory if we should be a kdump kernel. */
> - /* Do not move this variable as purgatory knows about it. */
> - .globl __kdump_flag
> -__kdump_flag:
> - .llong 0x0
> -
> #ifdef CONFIG_PPC_ISERIES
> /*
> * At offset 0x20, there is a pointer to iSeries LPAR data.
> @@ -112,6 +106,20 @@ __kdump_flag:
> .llong hvReleaseData-KERNELBASE
> #endif /* CONFIG_PPC_ISERIES */
>
> +#ifdef CONFIG_CRASH_DUMP
> + /* This flag is set to 1 by a loader if the kernel should run
> + * at the loaded address instead of the linked address. This
> + * is used by kexec-tools to keep the the kdump kernel in the
> + * crash_kernel region. The loader is responsible for
> + * observing the alignment requirement.
> + */
> + /* Do not move this variable as kexec-tools knows about it. */
> + . = 0x5c
> + .globl __run_at_load
> +__run_at_load:
> + .long 0x72756e30 /* "run0" -- relocate to 0 by default */
> +#endif
> +
> . = 0x60
> /*
> * The following code is used to hold secondary processors
> @@ -1391,8 +1399,8 @@ _STATIC(__after_prom_start)
> lis r25,PAGE_OFFSET@highest /* compute virtual base of kernel */
> sldi r25,r25,32
> #ifdef CONFIG_CRASH_DUMP
> - ld r7,__kdump_flag-_stext(r26)
> - cmpldi cr0,r7,1 /* kdump kernel ? - stay where we are */
> + lwz r7,__run_at_load-_stext(0)
> + cmplwi cr0,r7,1 /* kdump kernel ? - stay where we are */
Do we really want the flag to always be at 0x5c not 0x5c + kernel offset?
Also, comment "kdump kernel" needs to be updated to reflect the new
name.
Other than that, the patch series works for me.
Mikey
> bne 1f
> add r25,r25,r26
> #endif
> @@ -1416,11 +1424,11 @@ _STATIC(__after_prom_start)
> #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 relocatable
> + * variable __run_at_load, if it is set the kernel is treated as relocatable
> * kernel, otherwise it will be moved to PHYSICAL_START
> */
> - ld r7,__kdump_flag-_stext(r26)
> - cmpldi cr0,r7,1
> + lwz r7,__run_at_load-_stext(0)
> + cmplwi cr0,r7,1
> bne 3f
>
> li r5,__end_interrupts - _stext /* just copy interrupts */
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
next prev parent reply other threads:[~2008-10-23 3:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-22 4:56 [PATCH] Support for relocatable kdump kernel Milton Miller
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 [this message]
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
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=25820.1224732207@neuling.org \
--to=mikey@neuling.org \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=miltonm@bga.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;
as well as URLs for NNTP newsgroup(s).