All of lore.kernel.org
 help / color / mirror / Atom feed
From: Milton Miller <miltonm@bga.com>
To: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <michael@ellerman.id.au>,
	Ben Herrenschmidt <benh@kernel.crashing.org>,
	Simon Horman <horms@verge.net.au>,
	kexec@lists.infradead.org, linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 3/3] powerpc/ppc64/kdump: better flag for running relocatable
Date: Fri, 7 Nov 2008 07:52:31 -0600	[thread overview]
Message-ID: <b02389c29116c38699a129dfc66be127@bga.com> (raw)
In-Reply-To: <18687.62202.333736.269891@drongo.ozlabs.ibm.com>

On Oct 22, 2008, at 10:43 PM, Paul Mackerras wrote:
> Paul Mackerras writes:
>> Milton Miller writes:
>>> 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.
>>
>> Why is it easier on kexec-tools?  Doesn't kexec-tools know where it
>> put the kernel?

The archictecture code calls cross-platform code to identify what is
loaded.   It isn't specified if this is a shared mmap or a read into
a buffer.

>>
>> I'd much rather keep the flag inside the kdump kernel image, rather
>> than having kexec/kdump start using random fixed locations outside the
>> new kernel image.
>
> In fact the cliching argument is that when the kernel is loaded by OF
> or yaboot, we have no way to tell what will be at location 0x5c,
> whereas we know that the word at offset 0x5c in the kernel image will
> have been initialized to 0.  So we had better put the flag inside the
> kernel image.

Well, prom_init will copy the 256 bytes to 0 before the code checks
that location.

However, there is an arguement for using the same code from an epapr
or book-e relocatable, and that would need it at 0.   And today
the kexec tool does not do a shared mmap.  Since the change has
been made, I will make a new patch for kexec-tools.

milton


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

WARNING: multiple messages have this Message-ID (diff)
From: Milton Miller <miltonm@bga.com>
To: Paul Mackerras <paulus@samba.org>
Cc: Simon Horman <horms@verge.net.au>,
	kexec@lists.infradead.org, linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 3/3] powerpc/ppc64/kdump: better flag for running relocatable
Date: Fri, 7 Nov 2008 07:52:31 -0600	[thread overview]
Message-ID: <b02389c29116c38699a129dfc66be127@bga.com> (raw)
In-Reply-To: <18687.62202.333736.269891@drongo.ozlabs.ibm.com>

On Oct 22, 2008, at 10:43 PM, Paul Mackerras wrote:
> Paul Mackerras writes:
>> Milton Miller writes:
>>> 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.
>>
>> Why is it easier on kexec-tools?  Doesn't kexec-tools know where it
>> put the kernel?

The archictecture code calls cross-platform code to identify what is
loaded.   It isn't specified if this is a shared mmap or a read into
a buffer.

>>
>> I'd much rather keep the flag inside the kdump kernel image, rather
>> than having kexec/kdump start using random fixed locations outside the
>> new kernel image.
>
> In fact the cliching argument is that when the kernel is loaded by OF
> or yaboot, we have no way to tell what will be at location 0x5c,
> whereas we know that the word at offset 0x5c in the kernel image will
> have been initialized to 0.  So we had better put the flag inside the
> kernel image.

Well, prom_init will copy the 256 bytes to 0 before the code checks
that location.

However, there is an arguement for using the same code from an epapr
or book-e relocatable, and that would need it at 0.   And today
the kexec tool does not do a shared mmap.  Since the change has
been made, I will make a new patch for kexec-tools.

milton

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

Thread overview: 31+ 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-22 20:39   ` Milton Miller
2008-10-23  3:23   ` Michael Neuling
2008-10-23  3:23     ` Michael Neuling
2008-10-23  3:32   ` Paul Mackerras
2008-10-23  3:32     ` Paul Mackerras
2008-10-23  3:43     ` Paul Mackerras
2008-10-23  3:43       ` Paul Mackerras
2008-10-24  4:41       ` Michael Neuling
2008-10-24  4:41         ` Michael Neuling
2008-11-07 13:52       ` Milton Miller [this message]
2008-11-07 13:52         ` Milton Miller
2008-10-23 15:15   ` Mohan Kumar M
2008-10-23 15:15     ` Mohan Kumar M
2008-11-07 13:59     ` Milton Miller
2008-11-07 13:59       ` Milton Miller
2008-11-10 15:22       ` Mohan Kumar M
2008-11-10 15:22         ` Mohan Kumar M
2008-11-11 16:06         ` Milton Miller
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:39   ` Milton Miller
2008-10-22 20:47   ` 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   ` Milton Miller
2008-10-22 20:39 ` [PATCH 1/3] powerpc: kexec exit should not use magic numbers Milton Miller
2008-10-22 20:39   ` Milton Miller
2008-10-22 23:18   ` Simon Horman
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=b02389c29116c38699a129dfc66be127@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=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.