Re: [PATCH 4/4] kdump: update Documentation about crashkernel on arm64
On 2019/5/15 13:16, Bhupesh Sharma wrote: > On 05/07/2019 09:20 AM, Chen Zhou wrote: >> Now we support crashkernel=X,[high,low] on arm64, update the >> Documentation. >> >> Signed-off-by: Chen Zhou >> --- >> Documentation/admin-guide/kernel-parameters.txt | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt >> b/Documentation/admin-guide/kernel-parameters.txt >> index 268b10a..03a08aa 100644 >> --- a/Documentation/admin-guide/kernel-parameters.txt >> +++ b/Documentation/admin-guide/kernel-parameters.txt >> @@ -705,7 +705,7 @@ >> memory region [offset, offset + size] for that kernel >> image. If '@offset' is omitted, then a suitable offset >> is selected automatically. >> -[KNL, x86_64] select a region under 4G first, and >> +[KNL, x86_64, arm64] select a region under 4G first, and >> fall back to reserve region above 4G when '@offset' >> hasn't been specified. >> See Documentation/kdump/kdump.txt for further details. >> @@ -718,14 +718,14 @@ >> Documentation/kdump/kdump.txt for an example. >> crashkernel=size[KMG],high >> -[KNL, x86_64] range could be above 4G. Allow kernel >> +[KNL, x86_64, arm64] range could be above 4G. Allow kernel >> to allocate physical memory region from top, so could >> be above 4G if system have more than 4G ram installed. >> Otherwise memory region will be allocated below 4G, if >> available. >> It will be ignored if crashkernel=X is specified. >> crashkernel=size[KMG],low >> -[KNL, x86_64] range under 4G. When crashkernel=X,high >> +[KNL, x86_64, arm64] range under 4G. When crashkernel=X,high >> is passed, kernel could allocate physical memory region >> above 4G, that cause second kernel crash on system >> that require some amount of low memory, e.g. swiotlb >> > > IMO, it is a good time to update 'Documentation/kdump/kdump.txt' with this > patchset itself for both x86_64 and arm64, where we still specify only the > old format for 'crashkernel' boot-argument: > > Section: Boot into System Kernel > === > > On arm64, use "crashkernel=Y[@X]". Note that the start address of > the kernel, X if explicitly specified, must be aligned to 2MiB (0x20). > ... > > We can update this to add the new crashkernel=size[KMG],low or > crashkernel=size[KMG],high format as well. > > Thanks, > Bhupesh > > . Sure, we can also update here. Thanks, Chen Zhou
Re: [PATCH 0/4] support reserving crashkernel above 4G on arm64 kdump
Hi Bhupesh, On 2019/5/15 13:06, Bhupesh Sharma wrote: > +Cc kexec-list. > > Hi Chen, > > I think we are still in the quiet period of the merge cycle, but this is a > change which will be useful for systems like HPE Apollo where we are looking > at reserving crashkernel across a larger range. > > Some comments inline and in respective patch threads.. > > On 05/07/2019 09:20 AM, Chen Zhou wrote: >> This patch series enable reserving crashkernel on high memory in arm64. > > Please fix the patch subject, it should be v5. > Also please Cc the kexec-list (kexec@lists.infradead.org) for future versions > to allow wider review of the patchset. > >> We use crashkernel=X to reserve crashkernel below 4G, which will fail >> when there is no enough memory. Currently, crashkernel=Y@X can be used >> to reserve crashkernel above 4G, in this case, if swiotlb or DMA buffers >> are requierd, capture kernel will boot failure because of no low memory. > > ... ^^ required > > s/capture kernel will boot failure because of no low memory./capture kernel > boot will fail because there is no low memory available for allocation. > >> When crashkernel is reserved above 4G in memory, kernel should reserve >> some amount of low memory for swiotlb and some DMA buffers. So there may >> be two crash kernel regions, one is below 4G, the other is above 4G. Then >> Crash dump kernel reads more than one crash kernel regions via a dtb >> property under node /chosen, >> linux,usable-memory-range = . > > Please use consistent naming for the second kernel, better to use crash dump > kernel. > > I have tested this on my HPE Apollo machine and with crashkernel=886M,high > syntax, I can get the board to reserve a larger memory range for the > crashkernel (i.e. 886M): > > # dmesg | grep -i crash > [0.00] kexec_core: Reserving 256MB of low memory at 3560MB for > crashkernel (System low RAM: 2029MB) > [0.00] crashkernel reserved: 0x000bc5a0 - 0x000bfd00 > (886 MB) > > kexec/kdump can also work also work fine on the board. > > So, with the changes suggested in this cover letter and individual patches, > please feel free to add: > > Reviewed-and-Tested-by: Bhupesh Sharma > > Thanks, > Bhupesh > Thanks for you review and test. I will fix these later. Thanks, Chen Zhou >> Besides, we need to modify kexec-tools: >>arm64: support more than one crash kernel regions(see [1]) >> >> I post this patch series about one month ago. The previous changes and >> discussions can be retrived from: >> >> Changes since [v4] >> - reimplement memblock_cap_memory_ranges for multiple ranges by Mike. >> >> Changes since [v3] >> - Add memblock_cap_memory_ranges back for multiple ranges. >> - Fix some compiling warnings. >> >> Changes since [v2] >> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as >>two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate >>patch. >> >> Changes since [v1]: >> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c. >> - Remove memblock_cap_memory_ranges() i added in v1 and implement that >>in fdt_enforce_memory_region(). >>There are at most two crash kernel regions, for two crash kernel regions >>case, we cap the memory range [min(regs[*].start), max(regs[*].end)] >>and then remove the memory range in the middle. >> >> [1]: http://lists.infradead.org/pipermail/kexec/2019-April/022792.html >> [v1]: https://lkml.org/lkml/2019/4/2/1174 >> [v2]: https://lkml.org/lkml/2019/4/9/86 >> [v3]: https://lkml.org/lkml/2019/4/9/306 >> [v4]: https://lkml.org/lkml/2019/4/15/273 >> >> Chen Zhou (3): >>x86: kdump: move reserve_crashkernel_low() into kexec_core.c >>arm64: kdump: support reserving crashkernel above 4G >>kdump: update Documentation about crashkernel on arm64 >> >> Mike Rapoport (1): >>memblock: extend memblock_cap_memory_range to multiple ranges >> >> Documentation/admin-guide/kernel-parameters.txt | 6 +-- >> arch/arm64/include/asm/kexec.h | 3 ++ >> arch/arm64/kernel/setup.c | 3 ++ >> arch/arm64/mm/init.c| 72 >> +++-- >> arch/x86/include/asm/kexec.h| 3 ++ >> arch/x86/kernel/setup.c | 66 >> +++ >> include/linux/kexec.h | 5 ++ >> include/linux/memblock.h| 2 +- >> kernel/kexec_core.c | 56 +++ >> mm/memblock.c | 44 +++ >> 10 files changed, 157 insertions(+), 103 deletions(-) >> > > > . > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 2/3 v3] x86/kexec: Set the C-bit in the identity map page table when SEV is active
在 2019年05月15日 21:30, Borislav Petkov 写道:
> On Tue, Apr 30, 2019 at 03:44:20PM +0800, Lianbo Jiang wrote:
>> When SEV is active, the second kernel image is loaded into the
>> encrypted memory. Lets make sure that when kexec builds the
>> identity mapping page table it adds the memory encryption mask(C-bit).
>>
>> Co-developed-by: Brijesh Singh
>> Signed-off-by: Brijesh Singh
>> Signed-off-by: Lianbo Jiang
>> ---
>> arch/x86/kernel/machine_kexec_64.c | 12 +++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/machine_kexec_64.c
>> b/arch/x86/kernel/machine_kexec_64.c
>> index f60611531d17..11fe352f7344 100644
>> --- a/arch/x86/kernel/machine_kexec_64.c
>> +++ b/arch/x86/kernel/machine_kexec_64.c
>> @@ -56,6 +56,7 @@ static int init_transition_pgtable(struct kimage *image,
>> pgd_t *pgd)
>> pte_t *pte;
>> unsigned long vaddr, paddr;
>> int result = -ENOMEM;
>> +pgprot_t prot = PAGE_KERNEL_EXEC_NOENC;
>>
>> vaddr = (unsigned long)relocate_kernel;
>> paddr = __pa(page_address(image->control_code_page)+PAGE_SIZE);
>> @@ -92,7 +93,11 @@ static int init_transition_pgtable(struct kimage *image,
>> pgd_t *pgd)
>> set_pmd(pmd, __pmd(__pa(pte) | _KERNPG_TABLE));
>> }
>> pte = pte_offset_kernel(pmd, vaddr);
>> -set_pte(pte, pfn_pte(paddr >> PAGE_SHIFT, PAGE_KERNEL_EXEC_NOENC));
>> +
>> +if (sev_active())
>> +prot = PAGE_KERNEL_EXEC;
>> +
>> +set_pte(pte, pfn_pte(paddr >> PAGE_SHIFT, prot));
>> return 0;
>> err:
>> return result;
>> @@ -129,6 +134,11 @@ static int init_pgtable(struct kimage *image, unsigned
>> long start_pgtable)
>> level4p = (pgd_t *)__va(start_pgtable);
>> clear_page(level4p);
>>
>> +if (sev_active()) {
>> +info.page_flag |= _PAGE_ENC;
>> +info.kernpg_flag = _KERNPG_TABLE;
>
> kernpg_flag above is initialized to _KERNPG_TABLE_NOENC so you can do here
>
> info.kernpg_flag |= _PAGE_ENC;
>
> too, to make it even more clear what this does, right?
>
OK, i will modify it according to your suggestion and post again.
Thanks.
Lianbo
> IOW:
>
> diff --git a/arch/x86/kernel/machine_kexec_64.c
> b/arch/x86/kernel/machine_kexec_64.c
> index 783ce5184405..16c37fe489bc 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -135,8 +135,8 @@ static int init_pgtable(struct kimage *image, unsigned
> long start_pgtable)
> clear_page(level4p);
>
> if (sev_active()) {
> - info.page_flag |= _PAGE_ENC;
> - info.kernpg_flag = _KERNPG_TABLE;
> + info.page_flag |= _PAGE_ENC;
> + info.kernpg_flag |= _PAGE_ENC;
> }
>
> if (direct_gbpages)
>
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 2/3 v3] x86/kexec: Set the C-bit in the identity map page table when SEV is active
On Tue, Apr 30, 2019 at 03:44:20PM +0800, Lianbo Jiang wrote:
> When SEV is active, the second kernel image is loaded into the
> encrypted memory. Lets make sure that when kexec builds the
> identity mapping page table it adds the memory encryption mask(C-bit).
>
> Co-developed-by: Brijesh Singh
> Signed-off-by: Brijesh Singh
> Signed-off-by: Lianbo Jiang
> ---
> arch/x86/kernel/machine_kexec_64.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/machine_kexec_64.c
> b/arch/x86/kernel/machine_kexec_64.c
> index f60611531d17..11fe352f7344 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -56,6 +56,7 @@ static int init_transition_pgtable(struct kimage *image,
> pgd_t *pgd)
> pte_t *pte;
> unsigned long vaddr, paddr;
> int result = -ENOMEM;
> + pgprot_t prot = PAGE_KERNEL_EXEC_NOENC;
>
> vaddr = (unsigned long)relocate_kernel;
> paddr = __pa(page_address(image->control_code_page)+PAGE_SIZE);
> @@ -92,7 +93,11 @@ static int init_transition_pgtable(struct kimage *image,
> pgd_t *pgd)
> set_pmd(pmd, __pmd(__pa(pte) | _KERNPG_TABLE));
> }
> pte = pte_offset_kernel(pmd, vaddr);
> - set_pte(pte, pfn_pte(paddr >> PAGE_SHIFT, PAGE_KERNEL_EXEC_NOENC));
> +
> + if (sev_active())
> + prot = PAGE_KERNEL_EXEC;
> +
> + set_pte(pte, pfn_pte(paddr >> PAGE_SHIFT, prot));
> return 0;
> err:
> return result;
> @@ -129,6 +134,11 @@ static int init_pgtable(struct kimage *image, unsigned
> long start_pgtable)
> level4p = (pgd_t *)__va(start_pgtable);
> clear_page(level4p);
>
> + if (sev_active()) {
> + info.page_flag |= _PAGE_ENC;
> + info.kernpg_flag = _KERNPG_TABLE;
kernpg_flag above is initialized to _KERNPG_TABLE_NOENC so you can do here
info.kernpg_flag |= _PAGE_ENC;
too, to make it even more clear what this does, right?
IOW:
diff --git a/arch/x86/kernel/machine_kexec_64.c
b/arch/x86/kernel/machine_kexec_64.c
index 783ce5184405..16c37fe489bc 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -135,8 +135,8 @@ static int init_pgtable(struct kimage *image, unsigned long
start_pgtable)
clear_page(level4p);
if (sev_active()) {
- info.page_flag |= _PAGE_ENC;
- info.kernpg_flag = _KERNPG_TABLE;
+ info.page_flag |= _PAGE_ENC;
+ info.kernpg_flag |= _PAGE_ENC;
}
if (direct_gbpages)
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH 0/2] Improve reading mounts, fixing EFI/ACPI in common scenarios
On Mon, Apr 29, 2019 at 10:21:33AM +0200, Niklas Hambüchen wrote: > Hi, > > please find below two fixes to kexec-tools that improve its operation > on read-only file systems and initial ramdisks without /etc/mtab, > as well as making detection of sysfs and debugfs more robust by relying > on the file system type instead of conventional names that are not guaranteed. > > Best greetings, > Niklas > > Niklas Hambüchen (2): > x86: Check /proc/mounts before mtab for mounts > x86: Find mounts by FS type, not name Thanks Niklas, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] xen: Avoid overlapping segments in low memory
On Sun, Apr 28, 2019 at 01:52:12PM +0300, David Woodhouse wrote: > From: David Woodhouse > > Unlike Linux which creates a full identity mapping, Xen only maps those > segments which are explicitly requested. Therefore, xen_kexec_load() > silently adds in a segment from zero to 1MiB to ensure that VGA memory > and other things are accessible. > > However, this doesn't work when there are already segments to be loaded > under 1MiB, because the overlap causes Xen to reject the kexec_load. > > Be more careful and just infill the ranges which are required instead > of naïvely adding a full 0-1MiB segment at the end of the list. > > Signed-off-by: David Woodhouse Thanks David, applied. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v6 1/2] x86/kexec: Build identity mapping for EFI systab and ACPI tables
On 5/15/19 3:58 PM, Borislav Petkov wrote:
> On Wed, May 15, 2019 at 05:17:19AM +, Junichi Nomura wrote:
>> Hi Kairui,
>>
>> On 5/13/19 5:02 PM, Baoquan He wrote:
>>> On 05/13/19 at 09:50am, Borislav Petkov wrote:
On Mon, May 13, 2019 at 03:32:54PM +0800, Baoquan He wrote:
So we're going to try it again this cycle and if there's no fallout, it
will go upstream. If not, it will have to be fixed. The usual thing.
And I don't care if Kairui's patch fixes this one problem - judging by
the fragility of this whole thing, it should be hammered on one more
cycle on as many boxes as possible to make sure there's no other SNAFUs.
So go test it on more machines instead. I've pushed it here:
https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=next-merge-window
>>>
>>> Pingfan has got a machine to reproduce the kexec breakage issue, and
>>> applying these two patches fix it. He planned to paste the test result.
>>> I will ask him to try this branch if he has time, or I can get his
>>> machine to test.
>>>
>>> Junichi, also have a try on Boris's branch in NEC's test environment?
>>
>> while the patch set works on most of the machines I'm testing around,
>> I found kexec(1) fails to load kernel on a few machines if this patch
>> is applied. Those machines don't have IORES_DESC_ACPI_TABLES region
>> and have ACPI tables in IORES_DESC_ACPI_NV_STORAGE region instead.
>
> Why? What kind of machines are those?
I don't know. They are just general purpose Xeon-based servers
and not some special purpose machines. So I guess there are other
such machines in the wild.
> Why are the ACPI tables in NV storage?
>
> Looking at crash_setup_memmap_entries(), it already maps that type so I
> guess this is needed.
>
> + Rafael and leaving in the rest for reference.
>
>
>> So I think map_acpi_tables() should try to map both regions. I tried
>> following change in addition and it worked.
>>
>> --
>> Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.
>>
>>
>> diff --git a/arch/x86/kernel/machine_kexec_64.c
>> b/arch/x86/kernel/machine_kexec_64.c
>> index 3c77bdf..3837c4a 100644
>> --- a/arch/x86/kernel/machine_kexec_64.c
>> +++ b/arch/x86/kernel/machine_kexec_64.c
>> @@ -56,12 +56,22 @@ static int mem_region_callback(struct resource *res,
>> void *arg)
>> {
>> unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY;
>> struct init_pgtable_data data;
>> +int ret;
>>
>> data.info = info;
>> data.level4p = level4p;
>> flags = IORESOURCE_MEM | IORESOURCE_BUSY;
>> -return walk_iomem_res_desc(IORES_DESC_ACPI_TABLES, flags, 0, -1,
>> - , mem_region_callback);
>> +ret = walk_iomem_res_desc(IORES_DESC_ACPI_TABLES, flags, 0, -1,
>> + , mem_region_callback);
>> +if (ret && ret != -EINVAL)
>> +return ret;
>> +
>> +ret = walk_iomem_res_desc(IORES_DESC_ACPI_NV_STORAGE, flags, 0, -1,
>> + , mem_region_callback);
>> +if (ret && ret != -EINVAL)
>> +return ret;
>> +
>> +return 0;
>> }
>> #else
>> static int map_acpi_tables(struct x86_mapping_info *info, pgd_t *level4p) {
>> return 0; }
--
Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v6 1/2] x86/kexec: Build identity mapping for EFI systab and ACPI tables
On Wed, May 15, 2019 at 05:17:19AM +, Junichi Nomura wrote:
> Hi Kairui,
>
> On 5/13/19 5:02 PM, Baoquan He wrote:
> > On 05/13/19 at 09:50am, Borislav Petkov wrote:
> >> On Mon, May 13, 2019 at 03:32:54PM +0800, Baoquan He wrote:
> >> So we're going to try it again this cycle and if there's no fallout, it
> >> will go upstream. If not, it will have to be fixed. The usual thing.
> >>
> >> And I don't care if Kairui's patch fixes this one problem - judging by
> >> the fragility of this whole thing, it should be hammered on one more
> >> cycle on as many boxes as possible to make sure there's no other SNAFUs.
> >>
> >> So go test it on more machines instead. I've pushed it here:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=next-merge-window
> >
> > Pingfan has got a machine to reproduce the kexec breakage issue, and
> > applying these two patches fix it. He planned to paste the test result.
> > I will ask him to try this branch if he has time, or I can get his
> > machine to test.
> >
> > Junichi, also have a try on Boris's branch in NEC's test environment?
>
> while the patch set works on most of the machines I'm testing around,
> I found kexec(1) fails to load kernel on a few machines if this patch
> is applied. Those machines don't have IORES_DESC_ACPI_TABLES region
> and have ACPI tables in IORES_DESC_ACPI_NV_STORAGE region instead.
Why? What kind of machines are those?
Why are the ACPI tables in NV storage?
Looking at crash_setup_memmap_entries(), it already maps that type so I
guess this is needed.
+ Rafael and leaving in the rest for reference.
> So I think map_acpi_tables() should try to map both regions. I tried
> following change in addition and it worked.
>
> --
> Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.
>
>
> diff --git a/arch/x86/kernel/machine_kexec_64.c
> b/arch/x86/kernel/machine_kexec_64.c
> index 3c77bdf..3837c4a 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -56,12 +56,22 @@ static int mem_region_callback(struct resource *res, void
> *arg)
> {
> unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> struct init_pgtable_data data;
> + int ret;
>
> data.info = info;
> data.level4p = level4p;
> flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> - return walk_iomem_res_desc(IORES_DESC_ACPI_TABLES, flags, 0, -1,
> -, mem_region_callback);
> + ret = walk_iomem_res_desc(IORES_DESC_ACPI_TABLES, flags, 0, -1,
> + , mem_region_callback);
> + if (ret && ret != -EINVAL)
> + return ret;
> +
> + ret = walk_iomem_res_desc(IORES_DESC_ACPI_NV_STORAGE, flags, 0, -1,
> + , mem_region_callback);
> + if (ret && ret != -EINVAL)
> + return ret;
> +
> + return 0;
> }
> #else
> static int map_acpi_tables(struct x86_mapping_info *info, pgd_t *level4p) {
> return 0; }
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v6 1/2] x86/kexec: Build identity mapping for EFI systab and ACPI tables
On 5/15/19 10:08 AM, Dave Young wrote: > On 05/14/19 at 04:09pm, Ingo Molnar wrote: >>> Hmm, it seems caused by some WIP branch patches, I suspect below: >>> commit 124d6af5a5f559e516ed2c6ea857e889ed293b43 >>> x86/paravirt: Standardize 'insn_buff' variable names >> >> This commit had a bug which I fixed - could you try the latest -tip? > > Will do, but I do not use tip tree often, not sure which branch includes > the fix. > > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/ > Is it tip/master or tip/tip? Just in case, when I tried tip/master, one of test machines crashed in the same way as: https://lkml.org/lkml/2019/5/9/182 and I found this patch was needed: [PATCH] x86: intel_epb: Take CONFIG_PM into account https://lore.kernel.org/lkml/3431308.1mSSVdqTRr@kreacher/ -- Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
