On Sat, Sep 27, 2025 at 4:27 PM Cong Wang wrote:
>
> On Fri, Sep 26, 2025 at 2:01 AM Jarkko Sakkinen wrote:
> >
> > On Thu, Sep 18, 2025 at 03:25:59PM -0700, Cong Wang wrote:
> > > This patch series introduces multikernel architecture support, enabling
> > > multiple independent kernel instances
On Sun, Sep 21, 2025 at 1:45 AM Mike Rapoport wrote:
>
> From: "Mike Rapoport (Microsoft)"
>
> A vmalloc allocation is preserved using binary structure similar to
> global KHO memory tracker. It's a linked list of pages where each page
> is an array of physical address of pages in vmalloc area.
>
On Sun, Sep 21, 2025 at 6:26 PM Matthew Wilcox wrote:
>
> On Wed, Sep 17, 2025 at 08:36:09AM -0300, Jason Gunthorpe wrote:
> > On Tue, Sep 16, 2025 at 07:50:15PM -0700, Jason Miu wrote:
> > > This series transitions KHO from an xarray-based metadata tracking
> > > system with serialization to usin
On Wed, Sep 17, 2025 at 7:36 AM Jason Gunthorpe wrote:
>
> On Tue, Sep 16, 2025 at 07:50:15PM -0700, Jason Miu wrote:
> > This series transitions KHO from an xarray-based metadata tracking
> > system with serialization to using page table like data structures
> > that can be passed directly to the
On Thu, Sep 18, 2025 at 6:26 PM Cong Wang wrote:
>
> This patch series introduces multikernel architecture support, enabling
> multiple independent kernel instances to coexist and communicate on a
> single physical machine. Each kernel instance can run on dedicated CPU
> cores while sharing the un
On Wed, Sep 17, 2025 at 8:22 AM Jason Gunthorpe wrote:
>
> On Tue, Sep 16, 2025 at 07:50:16PM -0700, Jason Miu wrote:
> > + * kho_order_table
> > + * +---++
> > + * | 0 order| 1 order| 2 order ... | HUGETLB_PAGE_ORDER |
> > + * ++
> ->o-
> Next meeting will be on Monday, August 11 at 8am PDT (UTC-7), everybody is
> welcome: https://meet.google.com/rjn-dmzu-hgq
>
> Topics for the next meeting:
>
> - follow-up on sticky preservations with KHO, any additional insight
>provided for MSHV use cases
> - update on LUO
call
xa_init(&new_physxa->phys_bits);
Fixes: fc33e4b44b27 ("kexec: enable KHO support for memory preservation")
Signed-off-by: Pasha Tatashin
Acked-by: Mike Rapoport (Microsoft)
Cc: sta...@vger.kernel.org
---
kernel/kexec_handover.c | 28
1 file change
These fixes are taken out from: LUO v3 patch series:
https://lore.kernel.org/all/20250807014442.3829950-1-pasha.tatas...@soleen.com
Pasha Tatashin (3):
kho: init new_physxa->phys_bits to fix lockdep
kho: mm: Don't allow deferred struct page with KHO
kho: warn if KHO is disabled d
available. Add the missing warning message.
Signed-off-by: Pasha Tatashin
Acked-by: Mike Rapoport (Microsoft)
Acked-by: Pratyush Yadav
Cc: sta...@vger.kernel.org
---
kernel/kexec_handover.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/kexec_handover.c b/kernel/kexec_handover.c
index
them to be enabled together, and later we will have to
teach KHO to work properly with deferred struct page init kernel
feature.
Fixes: 990a950fe8fd ("kexec: add config option for KHO")
Signed-off-by: Pasha Tatashin
Acked-by: Mike Rapoport (Microsoft)
Acked-by: Pratyush
y deserialize_bitmap(), the reserved flag is not
> actually set (as can also be seen from the flags of the dumped page in
> the logs above). So drop the ClearPageReserved() calls.
>
> Fixes: fc33e4b44b271 ("kexec: enable KHO support for memory preservation")
> Signed-off-by: Pratyush Yadav
Reviewed-by: Pasha Tatashin
s so the right set
> of eyes can look at changes to those parts.
>
> Signed-off-by: Pratyush Yadav
Reviewed-by: Pasha Tatashin
Pasha
On Wed, Jun 11, 2025 at 9:06 AM Pratyush Yadav wrote:
>
> On Tue, Jun 10 2025, Pasha Tatashin wrote:
>
> >> > > I think it should be the other way around, KHO should depend on
> >> > > !DEFERRED_STRUCT_PAGE_INIT.
> >> >
> >> > Agreed
> > > I think it should be the other way around, KHO should depend on
> > > !DEFERRED_STRUCT_PAGE_INIT.
> >
> > Agreed, and this is what I first tried, but that does not work, there
> > is some circular dependency breaking the build. If you feel
> > adventurous you can try that :-)
>
> Hmm, weird,
On Tue, Jun 10, 2025 at 1:44 AM Mike Rapoport wrote:
>
> On Mon, Jun 09, 2025 at 04:07:50PM -0400, Pasha Tatashin wrote:
> > On Mon, Jun 9, 2025 at 3:36 PM Mike Rapoport wrote:
> > >
> > > Hi Pratyush,
> > >
> > > On Fri, Jun 06, 2025 at 06:23:0
s still in use for DMA,
> the new kernel image will be safe from that access because it resides
> in a memory region that is considered allocated in the old kernel and
> has a chance to reinitialize that component.
>
> Signed-off-by: Alexander Graf
> Acked-by: Baoquan He
Reviewed-by: Pasha Tatashin
On Mon, Jun 9, 2025 at 3:36 PM Mike Rapoport wrote:
>
> Hi Pratyush,
>
> On Fri, Jun 06, 2025 at 06:23:06PM +0200, Pratyush Yadav wrote:
> > Hi Mike,
> >
> > On Fri, Jun 06 2025, Mike Rapoport wrote:
> >
> > > On Thu, Jun 05, 2025 at 07:11:41PM +0200, Pratyush Yadav wrote:
> > >> From: Pratyush Ya
On Mon, Jun 2, 2025 at 9:11 AM Jason Gunthorpe wrote:
>
> On Sat, May 31, 2025 at 08:16:14PM -0700, David Rientjes wrote:
> > Pratyush asked about the relationship between KHO and LUO. Pasha noted
> > that KHO provides a state machine and in RFC v2 of LUO, LUO can drive KHO
> > which makes the KH
> Topics for the next meeting:
>
> - 20 min: presentation of LUO v2 design
Slides:
https://docs.google.com/presentation/d/17uYuw_KkD-gOiA6a6vDgHGzj-gDbmj7mjAb7ENlkZ5o/edit?slide=id.p#slide=id.p
> - check back on latest status of KHO series in mm staging trees and any
>pending concerns
>+
On Sun, May 18, 2025 at 11:51 AM Mike Rapoport wrote:
>
> On Sun, May 18, 2025 at 07:23:15AM -0700, Changyuan Lyu wrote:
> > From: Pasha Tatashin
> >
> > Lockdep shows the following warning:
> >
> > INFO: trying to register non-static key.
> > The cod
On Wed, Apr 2, 2025 at 12:47 PM Pratyush Yadav wrote:
>
> Hi,
>
> On Wed, Apr 02 2025, Changyuan Lyu wrote:
>
> > Hi Pratyush, Thanks for suggestions!
> >
> > On Thu, Mar 27, 2025 at 17:28:40 +, Pratyush Yadav
> > wrote:
> >> On Thu, Mar 27 2025, Jason Gunthorpe wrote:
> >>
> >> > On Thu, Ma
On Tue, Mar 25, 2025 at 2:58 AM Baoquan He wrote:
>
> On 03/24/25 at 12:18pm, Dave Young wrote:
> > On Thu, 20 Mar 2025 at 23:05, Changyuan Lyu wrote:
> > >
> > > From: Alexander Graf
> > >
> > > We have all generic code in place now to support Kexec with KHO. This
> > > patch adds a config opti
On Mon, Mar 24, 2025 at 12:18 AM Dave Young wrote:
>
> On Thu, 20 Mar 2025 at 23:05, Changyuan Lyu wrote:
> >
> > From: Alexander Graf
> >
> > We have all generic code in place now to support Kexec with KHO. This
> > patch adds a config option that depends on architecture support to
> > enable K
> To use the code, please boot the kernel with the "kho=on" command line
> parameter.
> KHO will automatically create scratch regions. If you want to set the
> scratch size explicitly you can use "kho_scratch=" command line parameter.
> For instance, "kho_scratch=16M,512M,256M" will reserve a 16 Mi
On Tue, Feb 11, 2025 at 7:49 AM Jason Gunthorpe wrote:
>
> On Mon, Feb 10, 2025 at 03:58:00PM -0500, Pasha Tatashin wrote:
> > >
> > > > +What:/sys/kernel/kho/dt_max
> > > > +Date:December 2023
> > > >
On Mon, Feb 10, 2025 at 3:22 PM Jason Gunthorpe wrote:
>
> On Thu, Feb 06, 2025 at 03:27:45PM +0200, Mike Rapoport wrote:
> > diff --git a/Documentation/ABI/testing/sysfs-kernel-kho
> > b/Documentation/ABI/testing/sysfs-kernel-kho
> > new file mode 100644
> > index ..f13b252bc303
> >
On Fri, Feb 7, 2025 at 8:38 PM Baoquan He wrote:
>
> On 02/06/25 at 08:28pm, Pasha Tatashin wrote:
> > On Thu, Feb 6, 2025 at 7:29 PM Andrew Morton
> > wrote:
> > >
> > > On Thu, 6 Feb 2025 15:27:40 +0200 Mike Rapoport wrote:
> > >
> &
On Sat, Feb 8, 2025 at 6:39 PM Cong Wang wrote:
>
> Hi Mike,
>
> On Thu, Feb 6, 2025 at 5:28 AM Mike Rapoport wrote:
> >
> > From: "Mike Rapoport (Microsoft)"
> >
> > Hi,
> >
> > This a next version of Alex's "kexec: Allow preservation of ftrace buffers"
> > series (https://lore.kernel.org/all/2
On Thu, Feb 6, 2025 at 7:29 PM Andrew Morton wrote:
>
> On Thu, 6 Feb 2025 15:27:40 +0200 Mike Rapoport wrote:
>
> > This a next version of Alex's "kexec: Allow preservation of ftrace buffers"
> > series (https://lore.kernel.org/all/20240117144704.602-1-g...@amazon.com),
> > just to make things
On Sun, Jun 5, 2022 at 10:56 PM Baoquan He wrote:
>
> On 05/27/22 at 02:55am, Pasha Tatashin wrote:
> > In some case initrd can be large. For example, it could be a netboot
> > image loaded by u-root, that is kexec'ing into it.
> >
> > The maximum size of initr
On Sun, Jun 5, 2022 at 10:45 PM Baoquan He wrote:
>
> On 05/27/22 at 02:55am, Pasha Tatashin wrote:
> > Currently, the maximum file size that is supported is 2G. This may be
> > too small in some cases. For example, kexec_file_load() system call
> > loads initramf
than 2G.
The first patch changes the return type from int to ssize_t in
kernel_read_file* functions.
The second patch increases the maximum initramfs file size to 4G.
Tested: verified that can kexec_file_load() works with 4G initramfs
on x86_64.
Pasha Tatashin (2):
fs/kernel_read_file: Allow to
buf_size.
Signed-off-by: Pasha Tatashin
---
fs/kernel_read_file.c| 38
include/linux/kernel_read_file.h | 32 +--
include/linux/limits.h | 1 +
3 files changed, 36 insertions(+), 35 deletions(-)
diff --git a/fs
ke it LONG_MAX, but it is safer to keep it
sane, and just increase it to 4G.
Increase the size to 4G, and make it obvious by having a new macro
that specifies the maximum file size supported by kexec_file_load()
syscall: KEXEC_FILE_SIZE_MAX.
Signed-off-by: Pasha Tatashin
---
kernel/kexec_file.c
On Thu, May 26, 2022 at 4:45 PM Pasha Tatashin
wrote:
>
> On Thu, May 26, 2022 at 4:38 PM Pasha Tatashin
> wrote:
> >
> > In some case initrd can be large. For example, it could be a netboot
> > image loaded by u-root, that is kexec'ing into it.
> >
>
On Thu, May 26, 2022 at 4:38 PM Pasha Tatashin
wrote:
>
> In some case initrd can be large. For example, it could be a netboot
> image loaded by u-root, that is kexec'ing into it.
>
> The maximum size of initrd is arbitrary set to 2G. Also, the limit is
> not very obvio
ke it LONG_MAX, but it is safer to keep it
sane, and just increase it to 4G.
Increase the size to 4G, and make it obvious by having a new macro
that specifies the maximum file size supported by kexec_file_load()
syscall: KEXEC_FILE_SIZE_MAX.
Signed-off-by: Pasha Tatashin
---
kernel/kexec_file.
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
Acked-by
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
Acked-by: Catalin Marinas
---
arch/arm64/include/asm/kexec.h| 6 ++
arch
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
Acked-by: Catalin Marinas
---
arch/arm64/kernel/machine_kexec.c | 43 ---
1 file changed, 43
second.
Signed-off-by: Pasha Tatashin
Tested-by: Pingfan Liu
Acked-by: Catalin Marinas
---
arch/arm64/include/asm/kexec.h | 3 +++
arch/arm64/kernel/asm-offsets.c | 1 +
arch/arm64/kernel/machine_kexec.c | 16 +++
arch/arm64/kernel/relocate_kernel.S | 31
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
Acked-by: Catalin Marinas
---
arch/arm64/kernel/cpu
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, and put relocation
function in its own section.
Signed-off-by: Pasha Tatashin
Acked-by: Catalin Marinas
---
arch/arm64/include/asm/sections.h | 1
n the mapping
it is executing from.
The makes no difference yet as the relocation code runs with the MMU
disabled.
Suggested-by: James Morse
Signed-off-by: Pasha Tatashin
Acked-by: Catalin Marinas
---
arch/arm64/include/asm/assembler.h | 19 +++
arch/arm64/include/asm/ke
is provided by trans_pgd_copy_el2_vectors() to
support this case.
Signed-off-by: Pasha Tatashin
Acked-by: Catalin Marinas
---
arch/arm64/Kconfig| 2 +-
arch/arm64/include/asm/kexec.h| 1 +
arch/arm64/kernel/asm-offsets.c | 1 +
arch/arm64/kernel/machine_kexec.c | 31
more arguments: once we enable MMU we
will need to pass information about page tables.
Pass kimage to arm64_relocate_new_kernel, and teach it to get the
required fields from kimage.
Signed-off-by: Pasha Tatashin
Acked-by: Catalin Marinas
---
arch/arm64/kernel/asm-offsets.c | 7 +++
arch
generated by the existing callers is unchanged.
Suggested-by: James Morse
Signed-off-by: Pasha Tatashin
Acked-by: Catalin Marinas
---
arch/arm64/include/asm/assembler.h | 30 ++---
arch/arm64/kernel/relocate_kernel.S | 13 +++--
2 files changed, 26 insertions
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
Acked-by: Catalin Marinas
---
arch/arm64/kernel/machine_kexec.c | 34
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
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
Acked-by: Catalin
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
Acked-by: Catalin Marinas
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
rnel.org/lkml/20190923203427.294286-1-pasha.tatas...@soleen.com
v4:
https://lore.kernel.org/lkml/20190909181221.309510-1-pasha.tatas...@soleen.com
v3:
https://lore.kernel.org/lkml/20190821183204.23576-1-pasha.tatas...@soleen.com
v2:
https://lore.kernel.org/lkml/20190817024629.26611-1-pasha.tatas.
On Thu, Sep 30, 2021 at 4:16 AM Will Deacon wrote:
>
> On Wed, Sep 29, 2021 at 11:54:55PM -0400, Pasha Tatashin wrote:
> > > > +/* Allocates pages for kexec page table */
> > > > +static void *kexec_page_alloc(void *arg)
> > > > +{
> > > &
> FWIW, I'm fine with this series. I think the only concern raised by
> James and not addressed is the possibility of the failure of the memory
> allocation for copying the page tables during kexec. If anyone will
> complain in the future, we can look into adding a fallback mechanism to
> do the re
On Wed, Sep 29, 2021 at 8:49 AM Will Deacon wrote:
>
> On Thu, Sep 16, 2021 at 07:13:10PM -0400, Pasha Tatashin wrote:
> > Changelog:
> > v17:
> > - Merged with 5.15-rc1 as requested by Catalin Marinas
> > - Added Tested-by: Pingfan Liu
>
> Thi
On Wed, Sep 29, 2021 at 12:43 PM Catalin Marinas
wrote:
>
> On Thu, Sep 16, 2021 at 07:13:25PM -0400, Pasha Tatashin wrote:
> > 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,
> >
Sorry, missed two comments:
> > /* Flush the reloc_code in preparation for its execution. */
> > dcache_clean_inval_poc((unsigned long)reloc_code,
> > -(unsigned long)reloc_code +
> > -arm64_relocate_new_kernel_size);
> > +
On Wed, Sep 29, 2021 at 8:45 AM Will Deacon wrote:
>
> On Thu, Sep 16, 2021 at 07:13:20PM -0400, Pasha Tatashin wrote:
> > Currently, relocation code declares start and end variables
> > which are used to compute its size.
> >
> > The better way to do this is to
> > +/* Allocates pages for kexec page table */
> > +static void *kexec_page_alloc(void *arg)
> > +{
> > + struct kimage *kimage = (struct kimage *)arg;
> > + struct page *page = kimage_alloc_control_pages(kimage, 0);
> > +
> > + if (!page)
> > + return NULL;
> > +
> > +
Hi Will,
> > + cpu_install_idmap();
> > + restart = (void
> > *)__pa_symbol(function_nocfi(__cpu_soft_restart));
> > + restart(is_hyp_nvhe(), kimage->start, kimage->arch.dtb_mem,
> > + 0, 0);
>
> Why can't you call:
>
> cpu_soft_rest
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
---
arch
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
n the mapping
it is executing from.
The makes no difference yet as the relocation code runs with the MMU
disabled.
Suggested-by: James Morse
Signed-off-by: Pasha Tatashin
---
arch/arm64/include/asm/assembler.h | 19 +++
arch/arm64/include/asm/kexec.h | 2 ++
arch/arm64/k
second.
Signed-off-by: Pasha Tatashin
Tested-by: Pingfan Liu
---
arch/arm64/include/asm/kexec.h | 3 +++
arch/arm64/kernel/asm-offsets.c | 1 +
arch/arm64/kernel/machine_kexec.c | 16 +++
arch/arm64/kernel/relocate_kernel.S | 31 +++--
4 files
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 a
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 +
arch/arm64/kernel
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 +--
arch
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
is provided by trans_pgd_copy_el2_vectors() to
support this case.
Signed-off-by: Pasha Tatashin
---
arch/arm64/Kconfig| 2 +-
arch/arm64/include/asm/kexec.h| 1 +
arch/arm64/kernel/asm-offsets.c | 1 +
arch/arm64/kernel/machine_kexec.c | 31
more arguments: once we enable MMU we
will need to pass information about page tables.
Pass kimage to arm64_relocate_new_kernel, and teach it to get the
required fields from kimage.
Signed-off-by: Pasha Tatashin
---
arch/arm64/kernel/asm-offsets.c | 7 +++
arch/arm64/kernel/machine_kexec.c
generated by the existing callers is unchanged.
Suggested-by: James Morse
Signed-off-by: Pasha Tatashin
---
arch/arm64/include/asm/assembler.h | 30 ++---
arch/arm64/kernel/relocate_kernel.S | 13 +++--
2 files changed, 26 insertions(+), 17 deletions(-)
diff --git
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
---
arch/arm64
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
---
arch/arm64/include/asm
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
-
rg/lkml/20190821183204.23576-1-pasha.tatas...@soleen.com
v2:
https://lore.kernel.org/lkml/20190817024629.26611-1-pasha.tatas...@soleen.com
v1:
https://lore.kernel.org/lkml/20190801152439.11363-1-pasha.tatas...@soleen.com
Pasha Tatashin (15):
arm64: kernel: add helper for booted at EL2 and not VHE
arm6
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
> >
79 matches
Mail list logo
