Quoting Petr Mladek (2021-04-07 10:03:28)
> On Tue 2021-03-30 20:05:20, Stephen Boyd wrote:
> > We can use the vmlinux_build_id array here now instead of open coding
> > it. This mostly consolidates code.
> >
> > Cc: Jiri Olsa
> > Cc: Alexei Starovoitov
> > Cc: Jessica Yu
> > Cc: Evan Green
>
From: Pingfan Liu
The intend of trans_pgd_map_page() was to map contigous range of VA
memory to the memory that is getting relocated during kexec. However,
since we are now using linear map instead of contigous range this
function is not needed
Signed-off-by: Pingfan Liu
[Changed commit
Now that kexec does its relocations with the MMU enabled, we no longer
need to clean the relocation data to the PoC.
Co-developed-by: James Morse
Signed-off-by: Pavel Tatashin
---
arch/arm64/kernel/machine_kexec.c | 40 ---
1 file changed, 40 deletions(-)
diff
This header contains only cpu_soft_restart() which is never used directly
anymore. So, remove this header, and rename the helper to be
cpu_soft_restart().
Suggested-by: James Morse
Signed-off-by: Pavel Tatashin
---
arch/arm64/include/asm/kexec.h| 6 ++
arch/arm64/kernel/cpu-reset.S
Now, that we have linear map page tables configured, keep MMU enabled
to allow faster relocation of segments to final destination.
Cavium ThunderX2:
Kernel Image size: 38M Iniramfs size: 46M Total relocation size: 84M
MMU-disabled:
relocation 7.489539915s
MMU-enabled:
relocation
Currently, relocation code declares start and end variables
which are used to compute its size.
The better way to do this is to use ld script incited, and put relocation
function in its own section.
Signed-off-by: Pavel Tatashin
---
arch/arm64/include/asm/sections.h | 1 +
To perform the kexec relocations with the MMU enabled, we need a copy
of the linear map.
Create one, and install it from the relocation code. This has to be done
from the assembly code as it will be idmapped with TTBR0. The kernel
runs in TTRB1, so can't use the break-before-make sequence on the
If we have a EL2 mode without VHE, the EL2 vectors are needed in order
to switch to EL2 and jump to new world with hypervisor privileges.
In preporation to MMU enabled relocation, configure our EL2 table now.
Suggested-by: James Morse
Signed-off-by: Pavel Tatashin
---
arch/arm64/Kconfig
Since we are going to keep MMU enabled during relocation, we need to
keep EL1 mode throughout the relocation.
Keep EL1 enabled, and switch EL2 only before enterying the new world.
Suggested-by: James Morse
Signed-off-by: Pavel Tatashin
---
arch/arm64/kernel/cpu-reset.h | 3 +--
Currently, during kexec load we are copying relocation function and
flushing it. However, we can also flush kexec relocation buffers and
if new kernel image is already in place (i.e. crash kernel), we can
also flush the new kernel image itself.
Signed-off-by: Pavel Tatashin
---
Currently, kexec relocation function (arm64_relocate_new_kernel) accepts
the following arguments:
head: start of array that contains relocation information.
entry: entry point for new kernel or purgatory.
dtb_mem:first and only argument to entry.
The number of
In case of kdump or when segments are already in place the relocation
is not needed, therefore the setup of relocation function and call to
it can be skipped.
Signed-off-by: Pavel Tatashin
Suggested-by: James Morse
---
arch/arm64/kernel/machine_kexec.c | 34 ++---
From: James Morse
kexec does dcache maintenance when it re-writes all memory. Our
dcache_by_line_op macro depends on reading the sanitised DminLine
from memory. Kexec may have overwritten this, so open-codes the
sequence.
dcache_by_line_op is a whole set of macros, it uses dcache_line_size
Users of trans_pgd may also need a copy of vector table because it is
also may be overwritten if a linear map can be overwritten.
Move setup of EL2 vectors from hibernate to trans_pgd, so it can be
later shared with kexec as well.
Suggested-by: James Morse
Signed-off-by: Pavel Tatashin
---
Currently, only hibernate sets custom ttbr0 with safe idmaped function.
Kexec, is also going to be using this functinality when relocation code
is going to be idmapped.
Move the setup seqeuence to a dedicated cpu_install_ttbr0() for custom
ttbr0.
Suggested-by: James Morse
Signed-off-by: Pavel
From: James Morse
Most of the hyp-stub's vector entries are invalid. These are each
a unique function that branches to itself. To move these into the
vectors, merge the ventry and invalid_vector macros and give each
one a unique name.
This means we can copy the hyp-stub as it is self contained
Replace places that contain logic like this:
is_hyp_mode_available() && !is_kernel_in_hyp_mode()
With a dedicated boolean function is_hyp_callable(). This will be needed
later in kexec in order to sooner switch back to EL2.
Suggested-by: James Morse
Signed-off-by: Pavel Tatashin
---
Changelog:
v13:
- Fixed a hang on ThunderX2, thank you Pingfan Liu for reporting
the problem. In relocation function we need civac not ivac, we
need to clean data in addition to invalidating it.
Since I was using ThunderX2 machine I also measured the new
From: James Morse
The hyp-stub's el1_sync code doesn't do very much, this can easily fit
in the vectors.
With this, all of the hyp-stubs behaviour is contained in its vectors.
This lets kexec and hibernate copy the hyp-stub when they need its
behaviour, instead of re-implementing it.
From: James Morse
Hibernate contains a set of temporary EL2 vectors used to 'park'
EL2 somewhere safe while all the memory is thrown in the air.
Making kexec do its relocations with the MMU on means they have to
be done at EL1, so EL2 has to be parked. This means yet another
set of vectors.
All
On Wed, Apr 07, 2021 at 05:59:19PM +0300, Andy Shevchenko wrote:
> On Wed, Apr 7, 2021 at 5:30 PM Luis Chamberlain wrote:
> > On Wed, Apr 07, 2021 at 10:33:44AM +0300, Andy Shevchenko wrote:
> > > On Wed, Apr 7, 2021 at 10:25 AM Luis Chamberlain
> > > wrote:
> > > > On Tue, Apr 06, 2021 at
On Wed, Apr 7, 2021 at 5:30 PM Luis Chamberlain wrote:
> On Wed, Apr 07, 2021 at 10:33:44AM +0300, Andy Shevchenko wrote:
> > On Wed, Apr 7, 2021 at 10:25 AM Luis Chamberlain wrote:
> > > On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
...
> > > Why is it worth it to add
On Fri, Apr 02, 2021 at 12:17:30PM +0200, Simon Horman wrote:
> This series aimes to:
>
> 1. Allow creation of dist tarball without self-referential hard links
> 2. Add a distckeck target
> 3. Add a GitHub workflow which to performs basic build testing
>
> A sample run of the workflow can be
On Tue, Apr 06, 2021 at 03:11:51PM +0100, Hongyan Xia wrote:
> From: Hongyan Xia
>
> We have observed a couple of cases where after a successful kexec, the
> crash kernel loaded in the 2nd kernel will run out of memory and
> crash. We narrowed down to two issues:
>
> 1. when preparing the
Liu Tao writes:
> Hello Eric,
>
> Please correct me if I'm wrong. After my research, I found that the
> KERNEL_VERSION
> check cannot be removed.
>
> In x86_64 case, function get_kernel_page_offset set different hard coded
> values into
> elf_info->page_offset according to KERNEL_VERSION, then
The following lines in kexec/kernel_version.c cause a crash dump to fail,
when the kernel is 4.4.262, or indeed any kernel whose patchlevel is >255.
if (major >= 256 || minor >= 256 || patch >= 256) {
fprintf(stderr, "Unsupported utsname.release: %s\n",
On Tue 2021-03-30 20:05:20, Stephen Boyd wrote:
> We can use the vmlinux_build_id array here now instead of open coding
> it. This mostly consolidates code.
>
> Cc: Jiri Olsa
> Cc: Alexei Starovoitov
> Cc: Jessica Yu
> Cc: Evan Green
> Cc: Hsin-Yi Wang
> Cc: Dave Young
> Cc: Baoquan He
>
On 4/7/2021 07:48, Corentin Labbe wrote:
Le Wed, Apr 07, 2021 at 07:28:26AM -0700, Bruce Mitchell a écrit :
On 4/7/2021 07:23, Corentin Labbe wrote:
Le Wed, Apr 07, 2021 at 07:13:04AM -0700, Bruce Mitchell a écrit :
On 4/7/2021 05:54, Corentin Labbe wrote:
Hello
I try to do kexec on a
On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> Here is the attempt to start cleaning it up by splitting out panic and
> oops helpers.
>
> At the same time convert users in header and lib folder to use
On Wed, Apr 7, 2021 at 10:25 AM Luis Chamberlain wrote:
>
> On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
> > diff --git a/include/linux/panic_notifier.h b/include/linux/panic_notifier.h
> > new file mode 100644
> > index ..41e32483d7a7
> > --- /dev/null
> > +++
On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> Here is the attempt to start cleaning it up by splitting out panic and
> oops helpers.
>
> At the same time convert users in header and lib folder to use
On Wed, Apr 07, 2021 at 10:33:44AM +0300, Andy Shevchenko wrote:
> On Wed, Apr 7, 2021 at 10:25 AM Luis Chamberlain wrote:
> >
> > On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
> > > diff --git a/include/linux/panic_notifier.h
> > > b/include/linux/panic_notifier.h
> > > new
On Wed, Apr 7, 2021 at 11:17 AM Kees Cook wrote:
>
> On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
> > kernel.h is being used as a dump for all kinds of stuff for a long time.
> > Here is the attempt to start cleaning it up by splitting out panic and
> > oops helpers.
> >
> >
Le Wed, Apr 07, 2021 at 07:28:26AM -0700, Bruce Mitchell a écrit :
> On 4/7/2021 07:23, Corentin Labbe wrote:
> > Le Wed, Apr 07, 2021 at 07:13:04AM -0700, Bruce Mitchell a écrit :
> >> On 4/7/2021 05:54, Corentin Labbe wrote:
> >>> Hello
> >>>
> >>> I try to do kexec on a cortina/gemini SoC.
>
On 4/7/2021 07:23, Corentin Labbe wrote:
Le Wed, Apr 07, 2021 at 07:13:04AM -0700, Bruce Mitchell a écrit :
On 4/7/2021 05:54, Corentin Labbe wrote:
Hello
I try to do kexec on a cortina/gemini SoC.
On a "normal" boot, kexec fail to find memory so I added crashkernel=8M to
cmdline. (kernel
Le Wed, Apr 07, 2021 at 07:13:04AM -0700, Bruce Mitchell a écrit :
> On 4/7/2021 05:54, Corentin Labbe wrote:
> > Hello
> >
> > I try to do kexec on a cortina/gemini SoC.
> > On a "normal" boot, kexec fail to find memory so I added crashkernel=8M to
> > cmdline. (kernel size is ~6M).
> > But
On 4/7/2021 05:54, Corentin Labbe wrote:
Hello
I try to do kexec on a cortina/gemini SoC.
On a "normal" boot, kexec fail to find memory so I added crashkernel=8M to
cmdline. (kernel size is ~6M).
But now, kernel fail to reserve memory:
Load Kern image from 0x3002 to 0x80 size 7340032
Some sub-1MB memory regions may be reserved by EFI boot services, and the
memory regions will be released later in the efi_free_boot_services().
Currently, always reserve all sub-1MB memory regions when the crashkernel
option is specified, but unfortunately EFI boot services may have already
Hello
I try to do kexec on a cortina/gemini SoC.
On a "normal" boot, kexec fail to find memory so I added crashkernel=8M to
cmdline. (kernel size is ~6M).
But now, kernel fail to reserve memory:
Load Kern image from 0x3002 to 0x80 size 7340032
39 matches
Mail list logo
