All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Dave Young <dyoung@redhat.com>
Cc: herbert@gondor.apana.org.au, bhe@redhat.com,
	ard.biesheuvel@linaro.org, catalin.marinas@arm.com,
	julien.thierry@arm.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
	dhowells@redhat.com, arnd@arndb.de,
	linux-arm-kernel@lists.infradead.org, mpe@ellerman.id.au,
	bauerman@linux.vnet.ibm.com, akpm@linux-foundation.org,
	davem@davemloft.net, vgoyal@redhat.com
Subject: Re: [PATCH v8 02/13] kexec_file: make an use of purgatory optional
Date: Thu, 1 Mar 2018 11:59:22 +0900	[thread overview]
Message-ID: <20180301025921.GL6019@linaro.org> (raw)
In-Reply-To: <20180228123359.GB2228@dhcp-128-65.nay.redhat.com>

On Wed, Feb 28, 2018 at 08:33:59PM +0800, Dave Young wrote:
> On 02/26/18 at 07:24pm, AKASHI Takahiro wrote:
> > On Fri, Feb 23, 2018 at 04:49:34PM +0800, Dave Young wrote:
> > > Hi AKASHI,
> > > 
> > > On 02/22/18 at 08:17pm, AKASHI Takahiro wrote:
> > > > On arm64, no trampline code between old kernel and new kernel will be
> > > > required in kexec_file implementation. This patch introduces a new
> > > > configuration, ARCH_HAS_KEXEC_PURGATORY, and allows related code to be
> > > > compiled in only if necessary.
> > > 
> > > Here also need the explanation about why no purgatory is needed, it would be
> > > required for kexec if no strong reason.
> > 
> > OK, I will add the reason:
> > On arm64, crash dump kernel's usable memory is protected by
> > *unmapping* it from kernel virtual space unlike other architectures
> > where the region is just made read-only.
> > So our key developers think that it is highly unlikely that the region
> > is accidentally corrupted and this rationalizes that digest check code
> > be also dropped from purgatory.
> > This greatly simplifies our purgatory without any need for a bit ugly
> > relocation stuff, i.e. arch_kexec_apply_relocations_add().
> > 
> > Please see:
> >    http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/545428.html
> > to find out how simple our purgatory was. All that it does is
> > to shuffle arguments and jump into a new kernel.
> > 
> > Without this patch, we would have to have purgatory with a space for
> > a hash value (purgatory_sha256_digest) which is never checked against.
> > 
> > Do you think it makes sense?
> 
> Hmm, it looks reasonable, I remember there could be some performance
> issue for a purgatory because of cache disabled for arm64. I do not
> object this.

Yeah, Pratyush(redhat) had expressed his concerns on slow boot-up of
the 2nd kernel which is due to hash value calculation.

-Takahiro AKASHI

> 
> [snip]
> 
> Thanks
> Dave

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

WARNING: multiple messages have this Message-ID (diff)
From: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 02/13] kexec_file: make an use of purgatory optional
Date: Thu, 1 Mar 2018 11:59:22 +0900	[thread overview]
Message-ID: <20180301025921.GL6019@linaro.org> (raw)
In-Reply-To: <20180228123359.GB2228@dhcp-128-65.nay.redhat.com>

On Wed, Feb 28, 2018 at 08:33:59PM +0800, Dave Young wrote:
> On 02/26/18 at 07:24pm, AKASHI Takahiro wrote:
> > On Fri, Feb 23, 2018 at 04:49:34PM +0800, Dave Young wrote:
> > > Hi AKASHI,
> > > 
> > > On 02/22/18 at 08:17pm, AKASHI Takahiro wrote:
> > > > On arm64, no trampline code between old kernel and new kernel will be
> > > > required in kexec_file implementation. This patch introduces a new
> > > > configuration, ARCH_HAS_KEXEC_PURGATORY, and allows related code to be
> > > > compiled in only if necessary.
> > > 
> > > Here also need the explanation about why no purgatory is needed, it would be
> > > required for kexec if no strong reason.
> > 
> > OK, I will add the reason:
> > On arm64, crash dump kernel's usable memory is protected by
> > *unmapping* it from kernel virtual space unlike other architectures
> > where the region is just made read-only.
> > So our key developers think that it is highly unlikely that the region
> > is accidentally corrupted and this rationalizes that digest check code
> > be also dropped from purgatory.
> > This greatly simplifies our purgatory without any need for a bit ugly
> > relocation stuff, i.e. arch_kexec_apply_relocations_add().
> > 
> > Please see:
> >    http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/545428.html
> > to find out how simple our purgatory was. All that it does is
> > to shuffle arguments and jump into a new kernel.
> > 
> > Without this patch, we would have to have purgatory with a space for
> > a hash value (purgatory_sha256_digest) which is never checked against.
> > 
> > Do you think it makes sense?
> 
> Hmm, it looks reasonable, I remember there could be some performance
> issue for a purgatory because of cache disabled for arm64. I do not
> object this.

Yeah, Pratyush(redhat) had expressed his concerns on slow boot-up of
the 2nd kernel which is due to hash value calculation.

-Takahiro AKASHI

> 
> [snip]
> 
> Thanks
> Dave

  reply	other threads:[~2018-03-01  2:59 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-22 11:17 [PATCH v8 00/13] arm64: kexec: add kexec_file_load() support AKASHI Takahiro
2018-02-22 11:17 ` AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 01/13] resource: add walk_system_ram_res_rev() AKASHI Takahiro
2018-02-22 11:17   ` AKASHI Takahiro
2018-02-23  8:36   ` Dave Young
2018-02-23  8:36     ` Dave Young
2018-03-20  1:43     ` Baoquan He
2018-03-20  1:43       ` Baoquan He
2018-03-20  3:12       ` AKASHI Takahiro
2018-03-20  3:12         ` AKASHI Takahiro
2018-03-20  3:48         ` Baoquan He
2018-03-20  3:48           ` Baoquan He
2018-02-22 11:17 ` [PATCH v8 02/13] kexec_file: make an use of purgatory optional AKASHI Takahiro
2018-02-22 11:17   ` AKASHI Takahiro
2018-02-23  8:49   ` Dave Young
2018-02-23  8:49     ` Dave Young
2018-02-26 10:24     ` AKASHI Takahiro
2018-02-26 10:24       ` AKASHI Takahiro
2018-02-28 12:33       ` Dave Young
2018-02-28 12:33         ` Dave Young
2018-03-01  2:59         ` AKASHI Takahiro [this message]
2018-03-01  2:59           ` AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 03/13] kexec_file, x86, powerpc: factor out kexec_file_ops functions AKASHI Takahiro
2018-02-22 11:17   ` AKASHI Takahiro
2018-02-23  9:24   ` [PATCH v8 03/13] kexec_file,x86,powerpc: " Dave Young
2018-02-23  9:24     ` Dave Young
2018-02-26 10:01     ` AKASHI Takahiro
2018-02-26 10:01       ` AKASHI Takahiro
2018-02-26 11:25       ` Philipp Rudo
2018-02-26 11:25         ` Philipp Rudo
2018-02-28 12:38       ` Dave Young
2018-02-28 12:38         ` Dave Young
2018-03-01  3:18         ` AKASHI Takahiro
2018-03-01  3:18           ` AKASHI Takahiro
2018-02-26 11:17   ` [PATCH v8 03/13] kexec_file, x86, powerpc: " Philipp Rudo
2018-02-26 11:17     ` Philipp Rudo
2018-02-27  2:03     ` AKASHI Takahiro
2018-02-27  2:03       ` AKASHI Takahiro
2018-02-27  9:26       ` Philipp Rudo
2018-02-27  9:26         ` Philipp Rudo
2018-02-22 11:17 ` [PATCH v8 04/13] x86: kexec_file: factor out elf core header related functions AKASHI Takahiro
2018-02-22 11:17   ` AKASHI Takahiro
2018-02-24  3:15   ` Dave Young
2018-02-24  3:15     ` Dave Young
2018-02-26  9:21     ` AKASHI Takahiro
2018-02-26  9:21       ` AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 05/13] kexec_file, x86: move re-factored code to generic side AKASHI Takahiro
2018-02-22 11:17   ` AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 06/13] asm-generic: add kexec_file_load system call to unistd.h AKASHI Takahiro
2018-02-22 11:17   ` AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 07/13] arm64: kexec_file: invoke the kernel without purgatory AKASHI Takahiro
2018-02-22 11:17   ` AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 08/13] arm64: kexec_file: load initrd and device-tree AKASHI Takahiro
2018-02-22 11:17   ` AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 09/13] arm64: kexec_file: add crash dump support AKASHI Takahiro
2018-02-22 11:17   ` AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 10/13] arm64: kexec_file: add Image format support AKASHI Takahiro
2018-02-22 11:17   ` AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 11/13] arm64: kexec_file: enable KEXEC_FILE config AKASHI Takahiro
2018-02-22 11:17   ` AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 12/13] include: pe.h: remove message[] from mz header definition AKASHI Takahiro
2018-02-22 11:17   ` AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 13/13] arm64: kexec_file: enable KEXEC_VERIFY_SIG for Image AKASHI Takahiro
2018-02-22 11:17   ` AKASHI Takahiro
2018-02-27  4:56 ` [PATCH v8 00/13] arm64: kexec: add kexec_file_load() support AKASHI Takahiro
2018-02-27  4:56   ` AKASHI Takahiro
2018-02-28 12:25   ` Dave Young
2018-02-28 12:25     ` Dave Young

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=20180301025921.GL6019@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --cc=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bauerman@linux.vnet.ibm.com \
    --cc=bhe@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=julien.thierry@arm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=vgoyal@redhat.com \
    --cc=will.deacon@arm.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 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.