On 05/25/21 at 07:41pm, Dave Young wrote:
> Hi Baoquan,
> > @@ -180,7 +191,7 @@ Dump-capture kernel config options (Arch Dependent,
> > i386 and x86_64)
> >
> > CONFIG_SMP=n
> >
> > - (If CONFIG_SMP=y, then specify maxcpus=1 on the kernel command line
> > + (If CONFIG_SMP=y, then speci
Hi Baoquan,
On 05/26/21 at 03:11pm, Baoquan He wrote:
> On 05/25/21 at 07:41pm, Dave Young wrote:
> > Hi Baoquan,
> > > @@ -180,7 +191,7 @@ Dump-capture kernel config options (Arch Dependent,
> > > i386 and x86_64)
> > >
> > > CONFIG_SMP=n
> > >
> > > - (If CONFIG_SMP=y, then specify maxcp
On Wed, 26 May 2021 11:53:45 +0800
Zhen Lei wrote:
> Fix some spelling mistakes in comments:
> suspeneded ==> suspended
> occuring ==> occurring
> wont ==> won't
> detatch ==> detach
> represntation ==> representation
> hexidecimal ==> hexadecimal
> delimeter ==> delimiter
> architecure ==> archi
Since kernel commit e2a073dde921 ("arm64: omit [_text, _stext) from
permanent kernel mapping"), the physical address of 'Kernel code' in
/proc/iomem is mapped from _text, instead, from _stext.
Taking the compatibility into account, it had better deduce the paddr of
_text despite of the unavailabil
In order for architectures to make use of locate_mem_hole_callback()
and avoid reinventing a square wheel, make this function global
and rename it to kexec_locate_mem_hole_callback() to match the
other global kexec symbols.
Signed-off-by: Marc Zyngier
---
include/linux/kexec.h | 1 +
kernel/kexe
When find_next_iomem_res() returns a resource, it doesn't
populate the child pointer (but does so with the parent).
As we are about to need to arse child resources, populate
this pointer as well.
Signed-off-by: Marc Zyngier
---
kernel/resource.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Provide an arm64-specific implementation for arch_kexec_locate_mem_hole(),
using the resource tree instead of memblock, and respecting
the reservations added by EFI.
This ensures that kexec_file is finally reliable.
Reported-by: Moritz Fischer
Signed-off-by: Marc Zyngier
---
arch/arm64/kernel/
This series is a complete departure from the approach I initially sent
almost a month ago[1]. Instead of trying to teach EFI, ACPI and other
subsystem to use memblock, I've decided to stick with the iomem
resource tree and use that exclusively for arm64.
This means that my current approach is (des
Once we have obtained a resource of a certain type from
find_next_iomem_res(), it doesn't necessarily mean that the whole
resource is usable, and we have cases where a child resource
denotes an exclusion in the initial resource.
Provide a new walker that deals with this exact case, and calls
a cal
