On Wed, 14 Mar 2018 11:22:40 +0800
Dave Young wrote:
> On 03/06/18 at 02:15pm, Michal Suchanek wrote:
> > Not all architectures implement KEXEC_FILE_LOAD. However, on some
> > archiectures KEXEC_FILE_LOAD is required when secure boot is
> > enabled in locked-down mode. Previously users had to sel
On Wed, 14 Mar 2018 11:41:30 +0800
Dave Young wrote:
> On 03/06/18 at 02:15pm, Michal Suchanek wrote:
> > Signed-off-by: Michal Suchanek
> > ---
> > kexec/kexec.8 | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/kexec/kexec.8 b/kexec/kexec.8
> > index e0131b4ea82
On 03/14/18 at 08:23am, Michal Suchánek wrote:
> On Wed, 14 Mar 2018 11:22:40 +0800
> Dave Young wrote:
>
> > On 03/06/18 at 02:15pm, Michal Suchanek wrote:
> > > Not all architectures implement KEXEC_FILE_LOAD. However, on some
> > > archiectures KEXEC_FILE_LOAD is required when secure boot is
>
On 03/14/18 at 08:25am, Michal Suchánek wrote:
> On Wed, 14 Mar 2018 11:41:30 +0800
> Dave Young wrote:
>
> > On 03/06/18 at 02:15pm, Michal Suchanek wrote:
> > > Signed-off-by: Michal Suchanek
> > > ---
> > > kexec/kexec.8 | 15 +++
> > > 1 file changed, 15 insertions(+)
> > >
> >
In the last couples of months, there were some problems reported [1],[2]
around arm64 kexec/kdump. Where those phenomenon look different,
the root cause would be that kexec/kdump doesn't take into account
crucial "reserved" regions of system memory and unintentionally corrupts
them.
Given that kex
On 14 March 2018 at 08:29, AKASHI Takahiro wrote:
> In the last couples of months, there were some problems reported [1],[2]
> around arm64 kexec/kdump. Where those phenomenon look different,
> the root cause would be that kexec/kdump doesn't take into account
> crucial "reserved" regions of syste
Hi Ingo,
do you have an idea about this? This problem is currently holding me back to
send a v2 of the patch set.
Thanks
Philipp
On Mon, 12 Mar 2018 15:40:16 +0800
Dave Young wrote:
> Hi Philipp,
> On 03/09/18 at 03:25pm, Philipp Rudo wrote:
> > Hi Dave,
> >
> > On Fri, 9 Mar 2018 13:19:40 +0
On Wed, Mar 14, 2018 at 11:10:53AM +0900, AKASHI Takahiro wrote:
> If kaslr-seed has a critical value in terms of security, is kexec-tools
> a right place? It is exposed to user space albeit for a short time of period.
The kernel zeroes the seed in the DT at boot time, so the current seed
isn't vi
On Wed, Mar 14, 2018 at 08:39:23AM +, Ard Biesheuvel wrote:
> On 14 March 2018 at 08:29, AKASHI Takahiro wrote:
> > In the last couples of months, there were some problems reported [1],[2]
> > around arm64 kexec/kdump. Where those phenomenon look different,
> > the root cause would be that kex
For kexec -p, after boot_cpuid is mapping into the range of [0,
threads_per_core), then if nr_cpus is small, we will have the bitmap
[0,..., nr_cpus, ..., boot_cpuid, ...). This patch chooses cpus inside
the range of [boot_cpuid - nr_cpus +1, ..., boot_cpuid] to be online.
With this patch and the
From: Mahesh Salgaonkar
The kernel boot parameter 'nr_cpus=' allows one to specify number of
possible cpus in the system. In the normal scenario the first cpu (cpu0)
that shows up is the boot cpu and hence it gets covered under nr_cpus
limit.
But this assumption will be broken in kdump scenario
This topic has a very long history. It comes from Mahesh Salgaonkar
For v3: https://patchwork.ozlabs.org/patch/834860/
I hope we can acquire it for "kexec -p" soon.
V4->V5:
improve the [1/3] implementation based on Benjamin's suggestion.
Mahesh Salgaonkar (1):
ppc64 boot: Wait for boot cpu
For kexec -p, the boot cpu can be not the cpu0, this causes the problem
to alloc paca[]. In theory, there is no requirement to assign cpu's logical
id as its present seq by device tree. But we have something like
cpu_first_thread_sibling(), which makes assumption on the mapping inside
a core. Hence
13 matches
Mail list logo
