On 2023/9/14 11:31, Baoquan He wrote:
> 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
On 2023/9/14 11:31, Baoquan He wrote:
> 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
On 2023/9/14 11:31, Baoquan He wrote:
> 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.
Reviewed-by: Zhen Lei
>
On 2023/9/5 16:29, Baoquan He wrote:
> On 09/04/23 at 10:47am, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2023/9/1 17:49, Baoquan He wrote:
>>>>> +
>>>>> + *high = true;
>>>>> + } else if (ret || !*crash_size) {
>>
On 2023/9/1 17:49, Baoquan He wrote:
>>> +
>>> + *high = true;
>>> + } else if (ret || !*crash_size) {
>> This check can be moved outside of #ifdef. Because even '!high', it's
>> completely
>> applicable. The overall adjustment is as follows:
> Hmm, the current logic is much easier
On 2023/8/29 20:16, Baoquan He wrote:
> So far, nobody calls functions parse_crashkernel_high() and
> parse_crashkernel_low(), remove both of them.
Reviewed-by: Zhen Lei
>
> Signed-off-by: Baoquan He
> ---
> include/linux/crash_core.h | 4
> kernel/crash_core.c| 18
On 2023/8/29 20:16, Baoquan He wrote:
> 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,
On 2023/8/29 20:16, Baoquan He wrote:
> 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,
On 2023/8/29 20:16, Baoquan He wrote:
> 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
On 2023/8/29 20:16, Baoquan He wrote:
> 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:
On 2023/8/29 20:16, Baoquan He wrote:
> 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.
Reviewed-by: Zhen Lei
>
> Signed-off-by: Baoquan He
>
On 2023/8/29 20:16, Baoquan He wrote:
> 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.
Reviewed-by: Zhen Lei
>
> Signed-off-by:
On 2023/7/24 21:34, Baoquan He wrote:
> Hi,
>
> On 07/21/23 at 04:17pm, thunder.leiz...@huaweicloud.com wrote:
>> From: Zhen Lei
>>
>> Unlike in the past, the low memory allocation direction of the crashkernel is
>> changed from top-down to bottom-up. As long as the DMA zone has sufficient
>>
On 2023/7/22 5:22, kernel test robot wrote:
> Hi,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on arm64/for-next/core]
> [also build test ERROR on linus/master v6.5-rc2 next-20230721]
> [If your patch is applied to the wrong git tree, kindly drop us a
On 2023/5/15 14:02, Baoquan He wrote:
> People complained the crashkernel reservation code flow is hard to
> follow, so add this document to explain the background, concepts and
> implementation of crashkernel reservation on arm64. Hope this can help
> people to understand it more easily.
On 2023/5/15 17:54, Baoquan He wrote:
> On arm64, reservation for 'crashkernel=xM,high' is taken by searching for
> suitable memory region top down. If the 'xM' of crashkernel high memory
> is reserved from high memory successfully, it will try to reserve
> crashkernel low memory later
On 2023/5/31 17:53, Baoquan He wrote:
> On 05/27/23 at 08:34pm, Zhen Lei wrote:
>> The crashk_low_res should be considered by /sys/kernel/kexec_crash_size
>> to support two crash kernel regions. Since crashk_res manages the memory
>> with high address and crashk_low_res manages the memory with
On 2023/5/31 15:41, Baoquan He wrote:
> On 05/31/23 at 10:19am, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2023/5/31 8:17, Baoquan He wrote:
>>> On 05/27/23 at 08:34pm, Zhen Lei wrote:
>>>> The check '(crashk_res.parent != NULL)' is added by
On 2023/5/31 8:17, Baoquan He wrote:
> On 05/27/23 at 08:34pm, Zhen Lei wrote:
>> The check '(crashk_res.parent != NULL)' is added by
>> commit e05bd3367bd3 ("kexec: fix Oops in crash_shrink_memory()"), but it's
>> stale now. Because if 'crashk_res' is not reserved, it will be zero in
>> size
On 2023/5/31 8:13, Baoquan He wrote:
> On 05/27/23 at 08:34pm, Zhen Lei wrote:
>> If the value of parameter 'new_size' is in the semi-open and semi-closed
>> interval (crashk_res.end - KEXEC_CRASH_MEM_ALIGN + 1, crashk_res.end], the
>> calculation result of ram_res is:
>> ram_res->start =
On 2023/5/28 8:08, kernel test robot wrote:
> Hi Zhen,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on akpm-mm/mm-everything]
> [also build test WARNING on linus/master v6.4-rc3 next-20230525]
> [If your patch is applied to the wrong git tree,
On 2023/4/13 22:30, Catalin Marinas wrote:
> On Thu, Apr 13, 2023 at 03:45:50PM +0800, Baoquan He wrote:
>> I am OK with this version, or the version with min(SZ_4G,
>> arm64_dma_phys_limit), or v4. Please help point out if I got your idea
>> correctly. Thanks a lot.
>
> I think we should
On 2023/4/7 6:02, Chen Jiahao wrote:
> Now "crashkernel=" parameter on riscv has been updated to support
> crashkernel=X,[high,low]. Through which we can reserve memory region
> above/within 32bit addressible DMA zone.
>
> Here update the parameter description accordingly.
Reviewed-by: Zhen
On 2023/4/7 20:58, Leizhen (ThunderTown) wrote:
>
>
> On 2023/4/7 20:03, Simon Horman wrote:
>> On Fri, Apr 07, 2023 at 06:02:05AM +0800, Chen Jiahao wrote:
>>> On riscv, the current crash kernel allocation logic is trying to
>>> allocate within 32bit add
On 2023/4/7 20:03, Simon Horman wrote:
> On Fri, Apr 07, 2023 at 06:02:05AM +0800, Chen Jiahao wrote:
>> On riscv, the current crash kernel allocation logic is trying to
>> allocate within 32bit addressible memory region by default, if
>> failed, try to allocate without 4G restriction.
>>
>> In
On 2023/3/26 21:02, Baoquan He wrote:
> In commit 031495635b46 ("arm64: Do not defer reserve_crashkernel() for
> platforms with no DMA memory zones"), reserve_crashkernel() is called
> much earlier in arm64_memblock_init() to avoid causing base apge
> mapping on platforms with no DMA meomry
On 2023/3/25 1:11, Catalin Marinas wrote:
> On Fri, Mar 24, 2023 at 09:18:35PM +0800, Baoquan He wrote:
>> Baoquan He (3):
>> arm64: kdump : take off the protection on crashkernel memory region
>> arm64: kdump: do not map crashkernel region specifically
>> arm64: kdump: defer the
On 2023/3/24 21:18, Baoquan He wrote:
> In commit 031495635b46 ("arm64: Do not defer reserve_crashkernel() for
> platforms with no DMA memory zones"), reserve_crashkernel() is called
> much earlier in arm64_memblock_init() to avoid causing base apge
> mapping on platforms with no DMA meomry
On 2023/3/24 21:18, Baoquan He wrote:
> After taking off the protection functions on crashkernel memory region,
> there's no need to map crashkernel region with page granularity during
> linear mapping.
>
> With this change, the system can make use of block or section mapping
> on linear
On 2023/3/24 21:18, Baoquan He wrote:
> Problem:
> ===
> On arm64, block and section mapping is supported to build page tables.
> However, currently it enforces to take base page mapping for the whole
> linear mapping if CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 is enabled and
> crashkernel
On 2023/3/24 22:53, Baoquan He wrote:
> Hi Leizhen,
>
> On 03/24/23 at 10:47am, Leizhen (ThunderTown) wrote:
> ..
>>>>>> 2) with the fixed CRASH_ADDR_LOW_MAX as 4G, we can easily fix the
>>>>>> problem of base page mapping for the wh
On 2023/3/24 1:25, Catalin Marinas wrote:
> On Mon, Mar 20, 2023 at 09:12:08PM +0800, Baoquan He wrote:
>> On 03/17/23 at 06:05pm, Catalin Marinas wrote:
>>> On Fri, Mar 17, 2023 at 11:09:13PM +0800, Baoquan He wrote:
In fact, what I want to achieve is we set CRASH_ADDR_LOW_MAX to 4G
On 2023/3/21 4:42, Chen Jiahao wrote:
> Now "crashkernel=" parameter on riscv has been updated to support
> crashkernel=X,[high,low]. Through which we can reserve memory region
> above/within 32bit addressible DMA zone.
>
> Here update the parameter description accordingly.
Reviewed-by: Zhen
On 2023/3/21 4:42, Chen Jiahao wrote:
> On riscv, the current crash kernel allocation logic is trying to
> allocate within 32bit addressible memory region by default, if
> failed, try to allocate without 4G restriction.
>
> In need of saving DMA zone memory while allocating a relatively large
On 2023/3/6 16:41, Baoquan He wrote:
> On arm64, reservation for 'crashkernel=xM,high' is taken by searching for
> suitable memory region top down. If the 'xM' of crashkernel high memory
> is reserved from high memory successfully, it will try to reserve
> crashkernel low memory later
On 2023/3/3 11:01, Baoquan He wrote:
> On 03/02/23 at 11:32am, Leizhen (ThunderTown) wrote:
> ..
>>> @@ -166,31 +169,51 @@ static void __init reserve_crashkernel(void)
>>> /* User specifies base address explicitly. */
>>> if (crash_base) {
On 2023/2/23 20:45, Baoquan He wrote:
> On arm64, reservation for 'crashkernel=xM,high' is taken by searching for
> suitable memory region top down. If the 'xM' of crashkernel high memory
> is reserved from high memory successfully, it will try to reserve
> crashkernel low memory later
On 2022/11/21 16:31, Baoquan He wrote:
> On 11/16/22 at 08:10pm, Zhen Lei wrote:
>> For crashkernel=X without '@offset', select a region within DMA zones
>> first, and fall back to reserve region above DMA zones. This allows
>> users to use the same configuration on multiple platforms.
>>
>>
On 2022/11/7 22:07, Catalin Marinas wrote:
> On Mon, Jul 11, 2022 at 05:03:18PM +0800, Zhen Lei wrote:
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 339ee84e5a61a0b..5390f361208ccf7 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -96,6 +96,14 @@
On 2022/11/15 21:30, Catalin Marinas wrote:
> On Tue, Nov 15, 2022 at 08:18:21PM +0800, Leizhen (ThunderTown) wrote:
>> On 2022/11/15 19:58, Will Deacon wrote:
>>> On Mon, Jul 11, 2022 at 05:03:17PM +0800, Zhen Lei wrote:
>>>> v2 --> v3:
>>>&
On 2022/11/15 19:58, Will Deacon wrote:
> On Mon, Jul 11, 2022 at 05:03:17PM +0800, Zhen Lei wrote:
>> v2 --> v3:
>> 1. Discard patch 3 in v2, a cleanup patch.
>
> Do you plan to respin this series, addressing the various comments on v3?
Yes, I haven't figured out where to make
On 2022/11/8 1:18, Catalin Marinas wrote:
> On Mon, Jul 11, 2022 at 05:03:18PM +0800, Zhen Lei wrote:
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>> b/Documentation/admin-guide/kernel-parameters.txt
>> index 2522b11e593f239..65a2c3a22a4b57d 100644
>> ---
On 2022/11/8 1:13, Catalin Marinas wrote:
> On Mon, Jul 11, 2022 at 05:03:19PM +0800, Zhen Lei wrote:
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 5390f361208ccf7..8539598f9e58b4d 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -138,6 +138,7 @@
On 2022/4/8 17:32, Baoquan He wrote:
> Hi, Lei
>
> On 02/27/22 at 11:07am, Zhen Lei wrote:
>> Changes since [v20]:
>> 1. Check whether crashkernel=Y,low is incorrectly configured or not
>> configured. Do different processing.
>> 2. Share the existing description of x86. The configuration of
On 2022/3/21 21:29, John Donnelly wrote:
> On 2/26/22 9:07 PM, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> There are following issues in arm64 kdump:
>> 1. We use crashkernel=X to reserve crashkernel below 4G, which
>> will fail when there is no enough low memory.
>
> "
On 2022/3/17 11:47, Baoquan He wrote:
> On 03/17/22 at 11:19am, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2022/3/17 10:36, Baoquan He wrote:
>>> On 03/16/22 at 09:11pm, Leizhen (ThunderTown) wrote:
>>>>
>>>>
>>>> On 2022/3/16 20:
On 2022/3/17 10:38, Baoquan He wrote:
> On 02/27/22 at 11:07am, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> There are following issues in arm64 kdump:
>> 1. We use crashkernel=X to reserve crashkernel below 4G, which
>> will fail when there is no enough low memory.
>> 2. If reserving crashkernel
On 2022/3/17 10:36, Baoquan He wrote:
> On 03/16/22 at 09:11pm, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2022/3/16 20:11, Baoquan He wrote:
>>> On 02/27/22 at 11:07am, Zhen Lei wrote:
> ..
>
>>> Hi leizhen,
>>>
>>> I m
On 2022/3/16 20:11, Baoquan He wrote:
> On 02/27/22 at 11:07am, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> There are following issues in arm64 kdump:
>> 1. We use crashkernel=X to reserve crashkernel below 4G, which
>> will fail when there is no enough low memory.
>> 2. If reserving crashkernel
On 2022/3/16 13:39, Baoquan He wrote:
> On 02/27/22 at 11:07am, Zhen Lei wrote:
>> The crashkernel=Y,low is an optional command-line option. When it doesn't
>> exist, kernel will try to allocate minimum required memory below 4G
>> automatically. Give it a unique error code to distinguish it
On 2022/3/15 20:21, Baoquan He wrote:
> On 03/15/22 at 07:57pm, Baoquan He wrote:
>> On 02/27/22 at 11:07am, Zhen Lei wrote:
>>> The crashkernel=Y,low is an optional command-line option. When it doesn't
>>> exist, kernel will try to allocate minimum required memory below 4G
>>> automatically.
On 2022/2/21 11:48, Baoquan He wrote:
> On 01/24/22 at 04:47pm, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> For arm64, the behavior of crashkernel=X has been changed, which
>> tries low allocation in DMA zone and fall back to high allocation
>> if it fails.
>>
>> We can also use
On 2022/2/21 11:22, Baoquan He wrote:
> On 02/14/22 at 02:22pm, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2022/2/11 18:39, Baoquan He wrote:
>>> On 01/24/22 at 04:47pm, Zhen Lei wrote:
>>>> From: Chen Zhou
>>>>
>>>> I
On 2022/2/16 18:20, Baoquan He wrote:
> On 02/16/22 at 10:58am, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2022/2/14 15:53, Leizhen (ThunderTown) wrote:
>>>
>>>
>>> On 2022/2/14 11:52, Baoquan He wrote:
>>>> On 01/24/22 at 04:47pm,
On 2022/2/14 15:53, Leizhen (ThunderTown) wrote:
>
>
> On 2022/2/14 11:52, Baoquan He wrote:
>> On 01/24/22 at 04:47pm, Zhen Lei wrote:
>> ..
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index 6c653a2c7cff052..a5d43feac0d7d9
On 2022/2/14 11:52, Baoquan He wrote:
> On 01/24/22 at 04:47pm, Zhen Lei wrote:
> ..
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 6c653a2c7cff052..a5d43feac0d7d96 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -71,6 +71,30 @@ phys_addr_t
On 2022/2/11 18:51, Baoquan He wrote:
> On 02/11/22 at 06:41pm, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2022/2/11 18:30, Baoquan He wrote:
>>> On 01/24/22 at 04:47pm, Zhen Lei wrote:
>>>> From: Chen Zhou
>>> ..
>>>> diff
On 2022/2/11 18:39, Baoquan He wrote:
> On 01/24/22 at 04:47pm, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> Introduce macro CRASH_ALIGN for alignment, macro CRASH_ADDR_LOW_MAX
>> for upper bound of low crash memory, macro CRASH_ADDR_HIGH_MAX for
>> upper bound of high crash memory, use macros
On 2022/2/11 18:30, Baoquan He wrote:
> On 01/24/22 at 04:47pm, Zhen Lei wrote:
>> From: Chen Zhou
> ..
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 6c653a2c7cff052..a5d43feac0d7d96 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -71,6
On 2022/1/12 22:45, Dave Kleikamp wrote:
> On 12/28/21 7:26AM, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> There are following issues in arm64 kdump:
>> 1. We use crashkernel=X to reserve crashkernel below 4G, which
>> will fail when there is no enough low memory.
>> 2. If reserving crashkernel
On 2022/1/7 16:13, Leizhen (ThunderTown) wrote:
>
>
> On 2021/12/25 9:53, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2021/12/24 14:36, Leizhen (ThunderTown) wrote:
>>>
>>>
>>> On 2021/12/24 1:26, Borislav Petkov wrote:
>>>> On
On 2021/12/25 9:53, Leizhen (ThunderTown) wrote:
>
>
> On 2021/12/24 14:36, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2021/12/24 1:26, Borislav Petkov wrote:
>>> On Wed, Dec 22, 2021 at 09:08:05PM +0800, Zhen Lei wrote:
>>>> From:
On 2021/12/31 17:22, Leizhen (ThunderTown) wrote:
>
>
> On 2021/12/30 19:08, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2021/12/30 18:40, Borislav Petkov wrote:
>>> On Thu, Dec 30, 2021 at 06:14:59PM +0800, Leizhen (ThunderTown) wrote:
>>>>
>
On 2021/12/30 19:08, Leizhen (ThunderTown) wrote:
>
>
> On 2021/12/30 18:40, Borislav Petkov wrote:
>> On Thu, Dec 30, 2021 at 06:14:59PM +0800, Leizhen (ThunderTown) wrote:
>>>
>>> Hi, Dave, Baoquan, Borislav:
>>> What do you think about the
On 2021/12/30 18:40, Borislav Petkov wrote:
> On Thu, Dec 30, 2021 at 06:14:59PM +0800, Leizhen (ThunderTown) wrote:
>>
>> Hi, Dave, Baoquan, Borislav:
>> What do you think about the introduction of parse_crashkernel_high_low()?
>> If everyone
>> doesn't
Hi, Dave, Baoquan, Borislav:
What do you think about the introduction of parse_crashkernel_high_low()? If
everyone
doesn't object, I'll bring it to the next version. But I'll make some
adjustments to the
patches, see below. If there's any objection, I still strongly recommend
removing the
On 2021/12/30 10:39, Leizhen (ThunderTown) wrote:
>
>
> On 2021/12/30 0:51, Borislav Petkov wrote:
>> On Wed, Dec 29, 2021 at 11:04:21PM +0800, Leizhen (ThunderTown) wrote:
>>> Chen Zhou and I tried to share the code because of a suggestion. After so
>>> m
On 2021/12/30 0:51, Borislav Petkov wrote:
> On Wed, Dec 29, 2021 at 11:04:21PM +0800, Leizhen (ThunderTown) wrote:
>> Chen Zhou and I tried to share the code because of a suggestion. After so
>> many
>> attempts, it doesn't seem to fit to make generic. Or maybe I haven't
On 2021/12/29 18:46, Dave Young wrote:
> On 12/29/21 at 11:03am, Borislav Petkov wrote:
>> On Wed, Dec 29, 2021 at 03:27:48PM +0800, Dave Young wrote:
>>> So I think you can unify the parse_crashkernel* in x86 first with just
>>> one function. And leave the further improvements to later work.
On 2021/12/29 18:38, Dave Young wrote:
> On 12/29/21 at 11:11am, Borislav Petkov wrote:
>> On Wed, Dec 29, 2021 at 03:45:12PM +0800, Dave Young wrote:
>>> BTW, I would suggest to wait for reviewers to response (eg. one week at
>>> least, or more due to the holidays) before updating another
On 2021/12/29 15:27, Dave Young wrote:
> On 12/29/21 at 10:27am, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2021/12/29 0:13, Borislav Petkov wrote:
>>> On Tue, Dec 28, 2021 at 09:26:01PM +0800, Zhen Lei wrote:
>>>> Use parse_crashkernel_high_low() to bri
On 2021/12/29 0:13, Borislav Petkov wrote:
> On Tue, Dec 28, 2021 at 09:26:01PM +0800, Zhen Lei wrote:
>> Use parse_crashkernel_high_low() to bring the parsing of
>> "crashkernel=X,high" and the parsing of "crashkernel=Y,low" together, they
>> are strongly dependent, make code logic clear and
On 2021/12/25 9:53, Leizhen (ThunderTown) wrote:
>>> This is exactly why I say that making those functions generic and shared
>>> might not be such a good idea, after all, because then you'd have to
>>> sprinkle around arch-specific stuff.
Hi Borislav and all:
Merry
On 2021/12/22 21:08, Zhen Lei wrote:
> Currently, there are two possible combinations of configurations.
> (1) crashkernel=X[@offset]
> (2) crashkernel=X,high, with or without crashkernel=X,low
>
> (1) has the highest priority, if it is configured correctly, (2) will be
> ignored. Similarly,
On 2021/12/24 14:36, Leizhen (ThunderTown) wrote:
>
>
> On 2021/12/24 1:26, Borislav Petkov wrote:
>> On Wed, Dec 22, 2021 at 09:08:05PM +0800, Zhen Lei wrote:
>>> From: Chen Zhou
>>>
>>> We will make the functions reserve_crashkernel()
On 2021/12/24 1:26, Borislav Petkov wrote:
> On Wed, Dec 22, 2021 at 09:08:05PM +0800, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> We will make the functions reserve_crashkernel() as generic, the
>> xen_pv_domain() check in reserve_crashkernel() is relevant only to
>> x86,
>
> Why is that so? Is
On 2021/12/23 23:48, Dave Kleikamp wrote:
> On 12/22/21 7:08AM, Zhen Lei wrote:
>> Currently, we parse the "linux,usable-memory-range" property in
>> early_init_dt_scan_chosen(), to obtain the specified memory range of the
>> crash kernel. We then reserve the required memory after
>>
On 2021/12/23 4:43, Borislav Petkov wrote:
> On Wed, Dec 22, 2021 at 09:08:04PM +0800, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> We want to make function reserve_crashkernel[_low](), which is implemented
> ^^
>
> Please use passive voice in your commit message: no "we" or "I", etc,
> and
On 2021/12/16 22:48, Borislav Petkov wrote:
> On Thu, Dec 16, 2021 at 08:08:30PM +0800, Leizhen (ThunderTown) wrote:
>> If the memory of 'crash_base' is successfully allocated at (1), because the
>> last
>> parameter CRASH_ADDR_LOW_MAX is the upper bound, so we can sur
On 2021/12/16 19:17, Borislav Petkov wrote:
> On Fri, Dec 10, 2021 at 02:55:28PM +0800, Zhen Lei wrote:
>> + * reserve_crashkernel() - reserves memory for crash kernel
>> + *
>> + * This function reserves memory area given in "crashkernel=" kernel command
>> + * line parameter. The memory
On 2021/12/16 20:08, Leizhen (ThunderTown) wrote:
>
>
> On 2021/12/16 19:07, Borislav Petkov wrote:
>> On Thu, Dec 16, 2021 at 10:46:12AM +0800, Leizhen (ThunderTown) wrote:
>>> The original value (1ULL << 32) is inaccurate
>>
>> I keep asking *why*?
On 2021/12/16 19:07, Borislav Petkov wrote:
> On Thu, Dec 16, 2021 at 10:46:12AM +0800, Leizhen (ThunderTown) wrote:
>> The original value (1ULL << 32) is inaccurate
>
> I keep asking *why*?
>
>> and it enlarged the CRASH_ADDR_LOW upper limit.
>
> $ git g
On 2021/12/16 9:10, Baoquan He wrote:
> On 12/15/21 at 02:28pm, Borislav Petkov wrote:
>> On Fri, Dec 10, 2021 at 02:55:26PM +0800, Zhen Lei wrote:
>>> @@ -518,7 +519,7 @@ static void __init reserve_crashkernel(void)
>>> }
>>> }
>>>
>>> - if (crash_base >= (1ULL << 32) &&
On 2021/12/15 19:16, Baoquan He wrote:
> On 12/15/21 at 11:01am, Catalin Marinas wrote:
>> On Wed, Dec 15, 2021 at 11:42:19AM +0800, Baoquan He wrote:
>>> On 12/14/21 at 07:24pm, Catalin Marinas wrote:
On Tue, Dec 14, 2021 at 08:07:58PM +0100, Borislav Petkov wrote:
> On Fri, Dec 10,
On 2021/12/14 19:40, Leizhen (ThunderTown) wrote:
>
>
> On 2021/12/10 14:55, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> We will make the functions reserve_crashkernel() as generic, the
>> xen_pv_domain() check in reserve_crashkernel() is relevant only to
&g
On 2021/12/15 3:24, Catalin Marinas wrote:
> On Tue, Dec 14, 2021 at 08:07:58PM +0100, Borislav Petkov wrote:
>> On Fri, Dec 10, 2021 at 02:55:25PM +0800, Zhen Lei wrote:
>>> From: Chen Zhou
>>>
>>> The lower bounds of crash kernel reservation and crash kernel low
>>> reservation are
On 2021/12/14 18:45, Baoquan He wrote:
>> +/* User specifies base address explicitly. */
> If you plan to repost, please take above sentence off either. Then we
> can say this patch is only doing code moving.
>
>> +unsigned long long start;
>> +
> OK, I can see that
On 2021/12/10 14:55, Zhen Lei wrote:
> From: Chen Zhou
>
> We will make the functions reserve_crashkernel() as generic, the
> xen_pv_domain() check in reserve_crashkernel() is relevant only to
> x86, the same as insert_resource() in reserve_crashkernel[_low]().
> So move xen_pv_domain() check
On 2021/12/14 3:54, Borislav Petkov wrote:
>> Subject: Re: [PATCH v17 01/10] x86: kdump: replace the hard-coded alignment
>> with macro CRASH_ALIGN
>
>>From Documentation/process/maintainer-tip.rst:
>
> "Patch subject
> ^
>
> The tip tree preferred format for patch subject
On 2021/12/13 21:37, Baoquan He wrote:
> On 12/10/21 at 02:55pm, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> The lower bounds of crash kernel reservation and crash kernel low
>> reservation are different, use the consistent value CRASH_ALIGN.
>>
>> Suggested-by: Dave Young
>> Signed-off-by: Chen
On 2021/12/13 21:17, Baoquan He wrote:
> On 12/10/21 at 02:55pm, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> Move CRASH_ALIGN to header asm/kexec.h for later use.
>>
>> Suggested-by: Dave Young
>> Suggested-by: Baoquan He
>
> I remember Dave and I discussed and suggested this when reviewing.
>
On 2021/12/9 1:09, Catalin Marinas wrote:
> On Tue, Nov 23, 2021 at 08:46:43PM +0800, Zhen Lei wrote:
>> diff --git a/arch/Kconfig b/arch/Kconfig
>> index 26b8ed11639da46..19256aa924c3b2c 100644
>> --- a/arch/Kconfig
>> +++ b/arch/Kconfig
>> @@ -24,6 +24,9 @@ config KEXEC_ELF
>> config
On 2021/12/1 10:55, Leizhen (ThunderTown) wrote:
>>> + }
>>>
>>> - memblock_cap_memory_range(cap_mem_addr, cap_mem_size);
>>> + memblock_cap_memory_range(rgn[0].base, rgn[0].size);
>>> + for (i = 1; i < MAX_USABLE_RANGES &&
On 2021/12/1 6:16, Rob Herring wrote:
> On Tue, Nov 23, 2021 at 08:46:45PM +0800, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> When reserving crashkernel in high memory, some low memory is reserved
>> for crash dump kernel devices and never mapped by the first kernel.
>> This memory range is
On 2021/10/20 22:19, Rob Herring wrote:
> On Wed, Oct 20, 2021 at 10:03:16AM +0800, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> When reserving crashkernel in high memory, some low memory is reserved
>> for crash dump kernel devices and never mapped by the first kernel.
>> This memory range is
On 2021/5/29 7:18, Eric W. Biederman wrote:
> Zhen Lei writes:
>
>> Fix some spelling mistakes in comments:
>> suspeneded ==> suspended
>> occuring ==> occurring
>> wont ==> won't
>> detatch ==> detach
>> represntation ==> representation
>> hexidecimal ==> hexadecimal
>> delimeter ==>
96 matches
Mail list logo
