-Original Message-
> > > > This patch set adds ZSTD compression support to makedumpfile. With ZSTD
> > > > compression
> > > > support, the vmcore dump size and time consumption can have a better
> > > > balance than
> > > > zlib/lzo/snappy.
> > > >
> > > > How to build:
> > > >
> > > >
Hi Tao Liu,
-Original Message-
> Hi Kazu,
>
> Thanks for reviewing the patchset!
>
> On Tue, Sep 14, 2021 at 07:04:24AM +, HAGIO KAZUHITO(萩尾 一仁) wrote:
> > Hi Tao Liu,
> >
> > Thanks for the patchset!
> >
> > -Original Message-
> > > This patch set adds ZSTD compression
The intend of trans_pgd_map_page() was to map contiguous range of VA
memory to the memory that is getting relocated during kexec. However,
since we are now using linear map instead of contiguous range this
function is not needed
Suggested-by: Pingfan Liu
Signed-off-by: Pasha Tatashin
---
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: Pasha Tatashin
---
arch/arm64/include/asm/kexec.h| 6 ++
arch/arm64/kernel/cpu-reset.S
To perform the kexec relocation 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
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
Now that kexec does its relocations with the MMU enabled, we no longer
need to clean the relocation data to the PoC.
Suggested-by: James Morse
Signed-off-by: Pasha Tatashin
---
arch/arm64/kernel/machine_kexec.c | 43 ---
1 file changed, 43 deletions(-)
diff --git
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: Pasha Tatashin
---
arch/arm64/include/asm/sections.h | 1 +
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 entering the new world.
Suggested-by: James Morse
Signed-off-by: Pasha Tatashin
---
arch/arm64/kernel/cpu-reset.h | 3 +--
Currently, only hibernate sets custom ttbr0 with safe idmaped function.
Kexec, is also going to be using this functionality when relocation code
is going to be idmapped.
Move the setup sequence to a dedicated cpu_install_ttbr0() for custom
ttbr0.
Suggested-by: James Morse
Signed-off-by: Pasha
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 preparation to MMU enabled relocation, configure our EL2 table now.
Kexec uses #HVC_SOFT_RESTART to branch to the new world, so extend
el1_sync vector that
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
kexec does dcache maintenance when it re-writes all memory. Our
dcache_by_line_op macro depends on reading the sanitized 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
which uses read_ctr for
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: Pasha Tatashin
---
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.
Signed-off-by: Pasha Tatashin
---
Replace places that contain logic like this:
is_hyp_mode_available() && !is_kernel_in_hyp_mode()
With a dedicated boolean function is_hyp_nvhe(). This will be needed
later in kexec in order to sooner switch back to EL2.
Suggested-by: James Morse
Signed-off-by: Pasha Tatashin
---
Changelog:
v17:
- Merged with 5.15-rc1 as requested by Catalin Marinas
- Added Tested-by: Pingfan Liu
v16:
- Merged with 5.14-rc4
v15:
- Changed trans_pgd_copy_el2_vectors() to use vector table that
only shared by kexec and hibernate. This way sync does
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: Pasha Tatashin
Suggested-by: James Morse
---
arch/arm64/kernel/machine_kexec.c | 34 ++---
> > In case we are so low on memory that trans_pgd_create_copy() fails to
> > allocate the linear map that uses the large pages (the size of the
> > page table is tiny) the kexec fails during kexec load time (not during
> > reboot time), as out of memory. The MMU enabled kexec reboot is always
> >
Christoph Hellwig writes:
> On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote:
>> Could you please provide more explicit explanation why inlining such an
>> helper is considered as bad practice and messy ?
>
> Because now we get architectures to all subly differ. Look at the mess
On Thu, Aug 26, 2021 at 11:03:21AM -0400, Pavel Tatashin wrote:
> On Tue, Aug 24, 2021 at 2:06 PM Catalin Marinas
> wrote:
> > > Enable MMU during kexec relocation in order to improve reboot performance.
> > >
> > > If kexec functionality is used for a fast system update, with a minimal
> > >
On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote:
> Could you please provide more explicit explanation why inlining such an
> helper is considered as bad practice and messy ?
Because now we get architectures to all subly differ. Look at the mess
for ioremap and the ioremap*
On Thu, Sep 16, 2021 at 4:59 AM Paul Moore wrote:
> On Mon, Sep 13, 2021 at 5:05 PM Paul Moore wrote:
> >
> > On Mon, Sep 13, 2021 at 10:02 AM Ondrej Mosnacek
> > wrote:
> > >
> > > Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> > > lockdown") added an implementation of
23 matches
Mail list logo
