On 09/12/23 at 01:59pm, Hari Bathini wrote:
> Currently, is_kdump_kernel() returns true in crash dump capture kernel
> for both kdump and fadump crash dump capturing methods, as both these
> methods set elfcorehdr_addr. Some restrictions enforced for crash dump
> capture kernel, based on is_kdump_k
On 09/12/23 at 01:59pm, Hari Bathini wrote:
> Currently, is_kdump_kernel() returns true when elfcorehdr_addr is set.
> While elfcorehdr_addr is set for kexec based kernel dump mechanism,
> alternate dump capturing methods like fadump [1] also set it to export
> the vmcore. Since, is_kdump_kernel()
Add two parameters 'low_size' and 'high' to function parse_crashkernel(),
later crashkernel=,high|low parsing will be added. Make adjustments in all
call sites of parse_crashkernel() in arch.
Signed-off-by: Baoquan He
Reviewed-by: Zhen Lei
---
arch/arm/kernel/setup.c | 3 ++-
arch
With the help of newly changed function parse_crashkernel() and
generic reserve_crashkernel_generic(), crashkernel reservation can be
simplified by steps:
1) Add a new header file , and define CRASH_ALIGN,
CRASH_ADDR_LOW_MAX, CRASH_ADDR_HIGH_MAX and
DEFAULT_CRASH_KERNEL_LOW_SIZE in ;
2) Add
So far, nobody calls functions parse_crashkernel_high() and
parse_crashkernel_low(), remove both of them.
Signed-off-by: Baoquan He
Reviewed-by: Zhen Lei
---
include/linux/crash_core.h | 4
kernel/crash_core.c| 18 --
2 files changed, 22 deletions(-)
diff --git a/
Both crashk_res and crashk_low_res are used to mark the reserved
crashkernel regions in iomem_resource tree. And later the generic
crashkernel resrvation will be added into crash_core.c. So move
crashk_res and crashk_low_res definition into crash_core.c to avoid
compiling error if CONFIG_CRASH_CORE
With the help of newly changed function parse_crashkernel() and
generic reserve_crashkernel_generic(), crashkernel reservation can be
simplified by steps:
1) Add a new header file , and define CRASH_ALIGN,
CRASH_ADDR_LOW_MAX, CRASH_ADDR_HIGH_MAX and
DEFAULT_CRASH_KERNEL_LOW_SIZE in ;
2) Add
In the current arm64, crashkernel=,high support has been finished after
several rounds of posting and careful reviewing. The code in arm64 which
parses crashkernel kernel parameters firstly, then reserve memory can be
a good example for other ARCH to refer to.
Whereas in x86_64, the code mixing cr
Now parse_crashkernel() is a real entry point for all kinds of
crahskernel parsing on any architecture.
And wrap the crahskernel=,high|low handling inside
CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION ifdeffery scope.
Signed-off-by: Baoquan He
---
include/linux/crash_core.h | 6 ++
kerne
With the help of newly changed function parse_crashkernel() and
generic reserve_crashkernel_generic(), crashkernel reservation can be
simplified by steps:
1) Add a new header file , and define CRASH_ALIGN,
CRASH_ADDR_LOW_MAX, CRASH_ADDR_HIGH_MAX and
DEFAULT_CRASH_KERNEL_LOW_SIZE in ;
2) Add
In all call sites of __parse_crashkernel(), the parameter 'name' is
hardcoded as "crashkernel=". So remove the unnecessary parameter 'name',
add local varibale 'name' inside __parse_crashkernel() instead.
Signed-off-by: Baoquan He
Reviewed-by: Zhen Lei
---
kernel/crash_core.c | 8
1 fi
In architecture like x86_64, arm64 and riscv, they have vast virtual
address space and usually have huge physical memory RAM. Their
crashkernel reservation doesn't have to be limited under 4G RAM,
but can be extended to the whole physical memory via crashkernel=,high
support.
Now add function rese
On Wed Sep 13, 2023 at 6:07 PM EEST, Jan Hendrik Farr wrote:
> On Wed, Sep 13, 2023, at 4:45 PM, Jarkko Sakkinen wrote:
> > On Tue Sep 12, 2023 at 11:49 PM EEST, Jan Hendrik Farr wrote:
> >>
> >> > These are sort of "tautological" arguments. There must be some
> >> > objective reasons why this arch
On Wed, Sep 13, 2023, at 4:45 PM, Jarkko Sakkinen wrote:
> On Tue Sep 12, 2023 at 11:49 PM EEST, Jan Hendrik Farr wrote:
>>
>> > These are sort of "tautological" arguments. There must be some
>> > objective reasons why this architecture was chosen instead of other
>> > (i.e. using what already pre-
On Tue Sep 12, 2023 at 11:49 PM EEST, Jan Hendrik Farr wrote:
>
> > These are sort of "tautological" arguments. There must be some
> > objective reasons why this architecture was chosen instead of
> > other (i.e. using what already pre-exists).
>
> I think I misunderstood you in my earlier reply. I
On Wed, Sep 13, 2023, at 4:00 PM, Philipp Rudo wrote:
> Hi Jan,
>
> All in all the code looks fine to me. Nevertheless I don't think UKI
> support should be added at the moment. This is because IMHO you
> basically reinterpret the kexec_file systemcall and thus add a new
> uapi to the kernel. On
On Mon, Sep 11, 2023 at 05:57:07PM +0300, Kirill A. Shutemov wrote:
> On Mon, Sep 11, 2023 at 10:56:36PM +0800, Dave Young wrote:
> > > early console in extract_kernel
> > > input_data: 0x00807eb433a8
> > > input_len: 0x00d26271
> > > output: 0x00807b00
> > > output_len: 0x0
Hi Jan,
All in all the code looks fine to me. Nevertheless I don't think UKI support
should be added at the moment. This is because IMHO you basically reinterpret
the kexec_file systemcall and thus add a new uapi to the kernel. Once
introduced it is extremely hard to remove or change an uapi again
18 matches
Mail list logo
