Re: [PATCH] arm64: kexec: include reboot.h

2023-04-20 Thread Will Deacon
On Tue, 18 Apr 2023 13:54:00 +0200, Simon Horman wrote: > Include reboot.h in machine_kexec.c for declaration of > machine_crash_shutdown. > > gcc-12 with W=1 reports: > > arch/arm64/kernel/machine_kexec.c:257:6: warning: no previous prototype for > 'machine_crash_shutdown'

Re: [PATCH v5] arm64: kdump: simplify the reservation behaviour of crashkernel=,high

2023-04-14 Thread Will Deacon
Hi, On Fri, Apr 07, 2023 at 10:24:19AM +0800, 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

Re: [PATCH v2 0/3] arm64: kdump : take off the protection on crashkernel memory region

2023-04-11 Thread Will Deacon
On Fri, 7 Apr 2023 09:15:04 +0800, 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 >

Re: [PATCH v4 0/2] arm64: kdump: Function supplement and performance optimization

2022-11-18 Thread Will Deacon
On Wed, 16 Nov 2022 20:10:42 +0800, Zhen Lei wrote: > v3 --> v4: > 1. Set DEFAULT_CRASH_KERNEL_LOW_SIZE to a fixed 128M. > 2. Some lightweight code adjustments based on Catalin Marinas's comments > > v2 --> v3: > 1. Discard patch 3 in v2, a cleanup patch. > > [...] Applied to arm64

Re: [PATCH v3 0/2] arm64: kdump: Function supplement and performance optimization

2022-11-15 Thread Will Deacon
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? Will ___ kexec mailing list kexec@lists.infradead.org

Re: [PATCH v3] arm64/kexec: Fix missing extra range for crashkres_low.

2022-09-01 Thread Will Deacon
On Wed, 31 Aug 2022 19:39:13 +0900, Levi Yun wrote: > Like crashk_res, Calling crash_exclude_mem_range function with > crashk_low_res area would need extra crash_mem range too. > > Add one more extra cmem slot in case of crashk_low_res is used. > > Applied to arm64 (for-next/fixes), thanks!

Re: [PATCH v3 1/2] arm64: kdump: Provide default size when crashkernel=Y,low is not specified

2022-08-02 Thread Will Deacon
On Mon, Jul 11, 2022 at 05:03:18PM +0800, Zhen Lei wrote: > To be consistent with the implementation of x86 and improve cross-platform > user experience. Try to allocate at least 256 MiB low memory automatically > for the case that crashkernel=,high is explicitly specified, while >

Re: [PATCH v9 0/4] unify the keyrings of arm64 and s390 with x86 to verify kexec'ed kernel signature

2022-07-06 Thread Will Deacon
On Wed, Jul 06, 2022 at 07:35:36AM -0400, Mimi Zohar wrote: > On Mon, 2022-07-04 at 09:51 +0800, Coiby Xu wrote: > > Currently when loading a kernel image via the kexec_file_load() system > > call, x86 can make use of three keyrings i.e. the .builtin_trusted_keys, > > .secondary_trusted_keys and

Re: [PATCH] arm64: crash_core: Export MODULES, VMALLOC, and VMEMMAP ranges

2022-03-07 Thread Will Deacon
On Wed, 9 Feb 2022 09:26:42 +, Huang Shijie wrote: > The following interrelated ranges are needed by the kdump crash tool: > MODULES_VADDR ~ MODULES_END, > VMALLOC_START ~ VMALLOC_END, > VMEMMAP_START ~ VMEMMAP_END > > Since these values change from time to time, it is

Re: [PATCH] arm64: crash_core: Export MODULES, VMALLOC, and VMEMMAP ranges

2022-02-16 Thread Will Deacon
On Wed, Feb 16, 2022 at 09:28:49AM +, Huang Shijie wrote: > Hi Will, > On Tue, Feb 15, 2022 at 04:44:23PM +, Will Deacon wrote: > > On Wed, Feb 09, 2022 at 09:26:42AM +, Huang Shijie wrote: > > > The following interrelated ranges are needed by

Re: [PATCH] arm64: crash_core: Export MODULES, VMALLOC, and VMEMMAP ranges

2022-02-15 Thread Will Deacon
On Wed, Feb 09, 2022 at 09:26:42AM +, Huang Shijie wrote: > The following interrelated ranges are needed by the kdump crash tool: > MODULES_VADDR ~ MODULES_END, > VMALLOC_START ~ VMALLOC_END, > VMEMMAP_START ~ VMEMMAP_END > > Since these values change from time to time, it

Re: [PATCH v17 00/10] support reserving crashkernel above 4G on arm64 kdump

2021-12-13 Thread Will Deacon
On Fri, Dec 10, 2021 at 03:15:00PM +0800, Kefeng Wang wrote: > > On 2021/12/10 14:55, Zhen Lei wrote: > > 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

Re: [PATCH v18 00/15] arm64: MMU enabled kexec relocation

2021-10-01 Thread Will Deacon
On Thu, 30 Sep 2021 14:30:58 +, Pasha Tatashin wrote: > Changelog: > v18: > - Addressed comments from Will Deacon > - Added Acks from Catalin Marinas > v17: > - Merged with 5.15-rc1 as requested by Catalin Marinas > - Added Tested-b

Re: [PATCH v17 08/15] arm64: kexec: configure EL2 vectors for kexec

2021-09-30 Thread Will Deacon
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) > > > +{ > > > + struct kimage *kimage = (struct kimage *)arg; > > > + struct page *page = kimage_alloc_control_pages(kimage,

Re: [PATCH 2/2] arm64: kexec_file: use more system keyrings to verify kernel image signature

2021-09-29 Thread Will Deacon
, but it looks like the first patch is the important one. So for the arm64 bit: Acked-by: Will Deacon Will ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v17 00/15] arm64: MMU enabled kexec relocation

2021-09-29 Thread Will Deacon
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 This looks pretty good to me. I've left some minor comments on a few of the patches, but other than those I'd

Re: [PATCH v17 10/15] arm64: kexec: use ld script for relocation function

2021-09-29 Thread Will Deacon
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 use ld script incited, and put relocation > function in its own section. "incited"? I don't

Re: [PATCH v17 08/15] arm64: kexec: configure EL2 vectors for kexec

2021-09-29 Thread Will Deacon
On Thu, Sep 16, 2021 at 07:13:18PM -0400, Pasha Tatashin wrote: > If we have a EL2 mode without VHE, the EL2 vectors are needed in order > to switch to EL2 and jump to new world with hypervisor privileges. > > In preparation to MMU enabled relocation, configure our EL2 table now. > > Kexec uses

Re: [PATCH v17 05/15] arm64: kexec: skip relocation code for inplace kexec

2021-09-29 Thread Will Deacon
On Thu, Sep 16, 2021 at 07:13:15PM -0400, Pasha Tatashin wrote: > 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 >

Re: [PATCH 0/2] arm64: kexec_file_load vs memory reservations

2021-05-18 Thread Will Deacon
[Fixing Bhupesh's email address] On Thu, Apr 29, 2021 at 02:35:31PM +0100, Marc Zyngier wrote: > It recently became apparent that using kexec with kexec_file_load() on > arm64 is pretty similar to playing Russian roulette. > > Depending on the amount of memory, the HW supported and the firmware

Re: [PATCH v2] kexec: move machine_kexec_post_load() to public interface

2021-02-23 Thread Will Deacon
On Mon, Feb 22, 2021 at 11:16:38PM -0600, Eric W. Biederman wrote: > Will Deacon writes: > > > On Fri, 19 Feb 2021 14:51:42 -0500, Pavel Tatashin wrote: > >> machine_kexec_post_load() is called after kexec load is finished. It must > >> declared in public

Re: [PATCH v2] kexec: move machine_kexec_post_load() to public interface

2021-02-22 Thread Will Deacon
On Fri, 19 Feb 2021 14:51:42 -0500, Pavel Tatashin wrote: > machine_kexec_post_load() is called after kexec load is finished. It must > declared in public header not in kexec_internal.h > > Fixes the following compiler warning: > > arch/arm64/kernel/machine_kexec.c:62:5: warning: no previous

Re: [PATCH 1/1] kexec: move machine_kexec_post_load() to public interface

2021-02-19 Thread Will Deacon
On Fri, Feb 19, 2021 at 02:06:31PM -0500, Pavel Tatashin wrote: > On Fri, Feb 19, 2021 at 12:53 PM Will Deacon wrote: > > > > On Mon, Feb 15, 2021 at 01:59:08PM -0500, Pavel Tatashin wrote: > > > machine_kexec_post_load() is called after kexec load is finished. It must >

Re: [PATCH 1/1] kexec: move machine_kexec_post_load() to public interface

2021-02-19 Thread Will Deacon
On Mon, Feb 15, 2021 at 01:59:08PM -0500, Pavel Tatashin wrote: > machine_kexec_post_load() is called after kexec load is finished. It must > be declared in public header not in kexec_internal.h Could you provide a log of what goes wrong without this patch, please? > Reported-by: kernel test

Re: (subset) [PATCH v10 00/18] arm64: MMU enabled kexec relocation

2021-01-27 Thread Will Deacon
On Mon, 25 Jan 2021 14:19:05 -0500, Pavel Tatashin wrote: > Changelog: > v10: > - Addressed a lot of comments form James Morse and from Marc Zyngier > - Added review-by's > - Synchronized with mainline > > [...] Applied the first 12 patches to arm64 (for-next/kexec), thanks!

Re: [PATCH v10 00/18] arm64: MMU enabled kexec relocation

2021-01-26 Thread Will Deacon
On Tue, Jan 26, 2021 at 06:05:10PM -0500, Pavel Tatashin wrote: > On Tue, Jan 26, 2021 at 5:58 PM Will Deacon wrote: > > > > Hi Pavel, > > > > On Mon, Jan 25, 2021 at 02:19:05PM -0500, Pavel Tatashin wrote: > > > Changelog: > > > v10: > > >

Re: [PATCH v10 00/18] arm64: MMU enabled kexec relocation

2021-01-26 Thread Will Deacon
Hi Pavel, On Mon, Jan 25, 2021 at 02:19:05PM -0500, Pavel Tatashin wrote: > Changelog: > v10: > - Addressed a lot of comments form James Morse and from Marc Zyngier > - Added review-by's > - Synchronized with mainline This series has been doing the rounds for a while, but

Re: [PATCH 2/2] arm64: Allocate crashkernel always in ZONE_DMA

2020-07-02 Thread Will Deacon
in ZONE_DMA32") > Cc: Johannes Weiner > Cc: Michal Hocko > Cc: Vladimir Davydov > Cc: James Morse > Cc: Mark Rutland > Cc: Will Deacon > Cc: Catalin Marinas > Cc: cgro...@vger.kernel.org > Cc: linux...@kvack.org > Cc: linux-arm-ker...@lists.infradead.org > Cc:

Re: [PATCH][v2] iommu: arm-smmu-v3: Copy SMMU table for kdump kernel

2020-06-08 Thread Will Deacon
On Tue, Jun 02, 2020 at 07:34:47PM +0530, Prabhakar Kushwaha wrote: > On Mon, Jun 1, 2020 at 1:10 PM Will Deacon wrote: > > On Thu, May 21, 2020 at 04:52:02PM +0530, Prabhakar Kushwaha wrote: > > > On Thu, May 21, 2020 at 2:53 PM Will Deacon wrote: > > > > On T

Re: [PATCH v6 2/2] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

2020-06-04 Thread Will Deacon
On Thu, Jun 04, 2020 at 02:04:58AM +0530, Bhupesh Sharma wrote: > On Wed, Jun 3, 2020 at 4:50 PM Kamlakant Patel wrote: > > > diff --git a/arch/arm64/kernel/crash_core.c > > > b/arch/arm64/kernel/crash_core.c > > > index 1f646b07e3e9..314391a156ee 100644 > > > ---

Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump

2020-06-04 Thread Will Deacon
On Thu, Jun 04, 2020 at 01:17:06AM +0530, Bhupesh Sharma wrote: > On Wed, Jun 3, 2020 at 9:03 PM John Donnelly > wrote: > > > On Jun 3, 2020, at 8:20 AM, chenzhou wrote: > > > On 2020/6/3 19:47, Prabhakar Kushwaha wrote: > > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > >

Re: [PATCH][v2] iommu: arm-smmu-v3: Copy SMMU table for kdump kernel

2020-06-01 Thread Will Deacon
On Thu, May 21, 2020 at 04:52:02PM +0530, Prabhakar Kushwaha wrote: > On Thu, May 21, 2020 at 2:53 PM Will Deacon wrote: > > > > On Tue, May 19, 2020 at 08:24:21AM +0530, Prabhakar Kushwaha wrote: > > > On Mon, May 18, 2020 at 9:25 PM Will Deacon wrote: > > > >

Re: kdump: Getting "warn_alloc" warning during boot of kdump kernel

2020-06-01 Thread Will Deacon
On Fri, May 15, 2020 at 04:28:13PM +0530, Prabhakar Kushwaha wrote: > We are getting "warn_alloc" warning during boot of kdump kernel. This > warning is observed with latest upstream tag (v5.7-rc5). Perhaps you can help to review:

Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump

2020-05-29 Thread Will Deacon
[+James Morse] On Thu, May 28, 2020 at 05:20:34PM -0500, John Donnelly wrote: > On 5/25/20 8:42 PM, Baoquan He wrote: > > On 05/21/20 at 05:38pm, Chen Zhou wrote: > > > This patch series enable reserving crashkernel above 4G in arm64. [...] > > > Chen Zhou (5): > > >x86: kdump: move

Re: [PATCH][v2] iommu: arm-smmu-v3: Copy SMMU table for kdump kernel

2020-05-21 Thread Will Deacon
On Tue, May 19, 2020 at 08:24:21AM +0530, Prabhakar Kushwaha wrote: > On Mon, May 18, 2020 at 9:25 PM Will Deacon wrote: > > On Mon, May 11, 2020 at 07:46:06PM -0700, Prabhakar Kushwaha wrote: > > > @@ -3272,6 +3281,23 @@ static int arm_smmu_init_l1_strtab(struct > >

Re: [PATCH][v2] iommu: arm-smmu-v3: Copy SMMU table for kdump kernel

2020-05-18 Thread Will Deacon
On Mon, May 11, 2020 at 07:46:06PM -0700, Prabhakar Kushwaha wrote: > An SMMU Stream table is created by the primary kernel. This table is > used by the SMMU to perform address translations for device-originated > transactions. Any crash (if happened) launches the kdump kernel which > re-creates

Re: [PATCH v3 1/2] arm64/crash_core: Export KERNELPACMASK in vmcoreinfo

2020-05-11 Thread Will Deacon
On Mon, 11 May 2020 18:31:55 +0530, Amit Daniel Kachhap wrote: > Recently arm64 linux kernel added support for Armv8.3-A Pointer > Authentication feature. If this feature is enabled in the kernel and the > hardware supports address authentication then the return addresses are > signed and stored

Re: [PATCH v2 1/2] arm64/crash_core: Export KERNELPACMASK in vmcoreinfo

2020-05-06 Thread Will Deacon
On Wed, May 06, 2020 at 05:32:56PM +0530, Amit Kachhap wrote: > On 5/4/20 10:47 PM, Will Deacon wrote: > > On Mon, Apr 27, 2020 at 11:55:01AM +0530, Amit Daniel Kachhap wrote: > > > diff --git a/arch/arm64/include/asm/compiler.h > > > b/arch/arm64/include/asm/com

Re: [PATCH v2 2/2] Documentation/vmcoreinfo: Add documentation for 'KERNELPACMASK'

2020-05-04 Thread Will Deacon
> Cc: Catalin Marinas > Cc: Will Deacon > Cc: Mark Rutland > Cc: Dave Young > Cc: Baoquan He > Signed-off-by: Amit Daniel Kachhap > --- > Documentation/admin-guide/kdump/vmcoreinfo.rst | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Doc

Re: [PATCH v2 1/2] arm64/crash_core: Export KERNELPACMASK in vmcoreinfo

2020-05-04 Thread Will Deacon
stacktrace purpose as well as to resolve the symbol name. > > This patch is similar to commit ec6e822d1a22d0eef ("arm64: expose user PAC > bit positions via ptrace") which exposes pac mask information via ptrace > interfaces. > > Cc: Catalin Marinas > Cc: Wil

Re: [PATCH v4 2/2] arm64: kexec_file: add crash dump support

2020-01-17 Thread Will Deacon
On Fri, Jan 17, 2020 at 03:38:33PM +0900, AKASHI Takahiro wrote: > On Thu, Jan 16, 2020 at 06:08:58PM +, Will Deacon wrote: > > On Tue, Jan 14, 2020 at 02:38:26PM +0900, AKASHI Takahiro wrote: > > > On Mon, Jan 13, 2020 at 11:21:06AM +, Will Deacon wrote: > > > &

Re: [PATCH v4 2/2] arm64: kexec_file: add crash dump support

2020-01-16 Thread Will Deacon
On Tue, Jan 14, 2020 at 02:38:26PM +0900, AKASHI Takahiro wrote: > On Mon, Jan 13, 2020 at 11:21:06AM +, Will Deacon wrote: > > On Fri, Jan 10, 2020 at 11:19:16AM -0500, Pavel Tatashin wrote: > > > On Fri, Jan 10, 2020 at 11:05 AM Will Deacon wrote: > > > > On T

Re: [PATCH v4 2/2] arm64: kexec_file: add crash dump support

2020-01-13 Thread Will Deacon
On Fri, Jan 10, 2020 at 11:19:16AM -0500, Pavel Tatashin wrote: > On Fri, Jan 10, 2020 at 11:05 AM Will Deacon wrote: > > > > On Thu, Jan 09, 2020 at 08:32:54AM +0000, Will Deacon wrote: > > > On Thu, Jan 09, 2020 at 09:46:55AM +0900, AKASHI Takahiro wrote: > > >

Re: [PATCH v4 2/2] arm64: kexec_file: add crash dump support

2020-01-10 Thread Will Deacon
On Thu, Jan 09, 2020 at 08:32:54AM +, Will Deacon wrote: > On Thu, Jan 09, 2020 at 09:46:55AM +0900, AKASHI Takahiro wrote: > > On Wed, Jan 08, 2020 at 05:48:39PM +0000, Will Deacon wrote: > > > On Mon, Dec 16, 2019 at 11:12:47AM +0900, AKASHI Takahiro wrote: > > >

Re: [PATCH v4 2/2] arm64: kexec_file: add crash dump support

2020-01-09 Thread Will Deacon
On Thu, Jan 09, 2020 at 09:46:55AM +0900, AKASHI Takahiro wrote: > On Wed, Jan 08, 2020 at 05:48:39PM +, Will Deacon wrote: > > On Mon, Dec 16, 2019 at 11:12:47AM +0900, AKASHI Takahiro wrote: > > > Enabling crash dump (kdump) includes > > > * prepare contents of ELF

Re: [PATCH v4 2/2] arm64: kexec_file: add crash dump support

2020-01-08 Thread Will Deacon
e" and > "linux,elfcorehdr", which represent respectively a memory range > to be used by crash dump kernel and the header's location > > Signed-off-by: AKASHI Takahiro > Cc: Catalin Marinas > Cc: Will Deacon > Reviewed-by: James Morse > Tested-and-revi

Re: [PATCH v8 00/25] arm64: MMU enabled kexec relocation

2020-01-08 Thread Will Deacon
On Wed, Dec 04, 2019 at 10:59:13AM -0500, Pavel Tatashin wrote: > Many changes compared to version 6, so I decided to send it out now. > James Morse raised an important issue to which I do not have a solution > yet. But would like to discuss it. Thanks. In the meantime, I've queued the first 10

Re: [PATCH v3 1/2] libfdt: include fdt_addresses.c

2020-01-08 Thread Will Deacon
On Mon, Dec 09, 2019 at 12:03:44PM +0900, AKASHI Takahiro wrote: > In the implementation of kexec_file_loaded-based kdump for arm64, > fdt_appendprop_addrrange() will be needed. > > So include fdt_addresses.c in making libfdt. > > Signed-off-by: AKASHI Takahiro > Cc: Rob Herring > Cc: Frank

Re: [PATCH v6 0/4] support reserving crashkernel above 4G on arm64 kdump

2019-12-18 Thread Will Deacon
On Wed, Dec 18, 2019 at 10:07:59AM +0800, Chen Zhou wrote: > Friendly ping... You broke the build: https://lore.kernel.org/lkml/201909010744.cde940pv%...@intel.com https://lore.kernel.org/lkml/201909010704.4m9y2sg7%...@intel.com So I doubt anybody will seriously look at this. Will

Re: [PATCH v5 0/5] Append new variables to vmcoreinfo (TCR_EL1.T1SZ for arm64 and MAX_PHYSMEM_BITS for all archs)

2019-12-03 Thread Will Deacon
On Sat, Nov 30, 2019 at 01:35:36AM +0530, Bhupesh Sharma wrote: > On Fri, Nov 29, 2019 at 3:54 PM Will Deacon wrote: > > On Fri, Nov 29, 2019 at 01:53:36AM +0530, Bhupesh Sharma wrote: > > > Changes since v4: > > > > > > - v4 can be seen here

Re: [PATCH v5 0/5] Append new variables to vmcoreinfo (TCR_EL1.T1SZ for arm64 and MAX_PHYSMEM_BITS for all archs)

2019-11-29 Thread Will Deacon
On Fri, Nov 29, 2019 at 01:53:36AM +0530, Bhupesh Sharma wrote: > Changes since v4: > > - v4 can be seen here: > http://lists.infradead.org/pipermail/kexec/2019-November/023961.html > - Addressed comments from Dave and added patches for documenting > new variables appended to

Re: [PATCH v16 06/16] lib: fdt: add a helper function for handling memory range property

2018-12-06 Thread Will Deacon
Hi Rob, Thanks for reviewing this. On Thu, Dec 06, 2018 at 08:47:04AM -0600, Rob Herring wrote: > On Wed, Nov 14, 2018 at 11:52 PM AKASHI Takahiro > wrote: > > > > Added function, fdt_setprop_reg(), will be used later to handle > > kexec-specific property in arm64's kexec_file implementation. >

Re: [PATCH v16 06/16] lib: fdt: add a helper function for handling memory range property

2018-11-30 Thread Will Deacon
[moving some DT people to TO:] On Thu, Nov 15, 2018 at 02:52:45PM +0900, AKASHI Takahiro wrote: > Added function, fdt_setprop_reg(), will be used later to handle > kexec-specific property in arm64's kexec_file implementation. > It will possibly be merged into libfdt in the future. > >

Re: [PATCH v16 15/16] arm64: kexec_file: add kernel signature verification support

2018-11-30 Thread Will Deacon
f binary. Since arm64's "Image" can also be seen as a PE file as far as > CONFIG_EFI is enabled, we adopt this format for kernel signing. > > You can create a signed kernel image with: > $ sbsign --key ${KEY} --cert ${CERT} Image > > Signed-off-by: AKASHI Takahir

Re: [PATCH v16 16/16] arm64: kexec_file: add kaslr support

2018-11-30 Thread Will Deacon
We don't have any "switch" to turn off this feature directly, but still > can suppress it by passing "nokaslr" as a kernel boot argument. > > Signed-off-by: AKASHI Takahiro > Cc: Catalin Marinas > Cc: Will Deacon > --- > arch/arm64/kernel/machine_kexec_file.

Re: [Bug Report] kdump crashes after latest EFI memblock changes on arm64 machines with large number of CPUs

2018-11-05 Thread Will Deacon
On Fri, Nov 02, 2018 at 02:44:10AM +0530, Bhupesh Sharma wrote: > With the latest EFI changes for memblock reservation across kdump > kernel from Ard (Commit 71e0940d52e107748b270213a01d3b1546657d74 > ["efi: honour memory reservations passed via a linux specific config > table"]), we hit a panic

Re: [PATCH v2] arm64, kaslr: export offset in VMCOREINFO ELF notes

2018-07-31 Thread Will Deacon
On Tue, Jul 31, 2018 at 10:19:35AM +0100, James Morse wrote: > Hi Bhupesh, > > On 30/07/18 07:24, Bhupesh Sharma wrote: > > Include KASLR offset in arm64 VMCOREINFO ELF notes to assist in > > debugging. vmcore parsing in user-space already expects this value in > > the notes and we are providing

Re: [PATCH v3.1 0/4] arm64: kexec,kdump: fix boot failures on acpi-only system

2018-07-23 Thread Will Deacon
On Tue, Jul 17, 2018 at 02:12:23PM +0900, AKASHI Takahiro wrote: > On Fri, Jul 13, 2018 at 07:49:45AM +0200, Ard Biesheuvel wrote: > > On 13 July 2018 at 02:34, AKASHI Takahiro > > wrote: > > > On Thu, Jul 12, 2018 at 05:49:19PM +0100, Will Deacon wrote: > > >

Re: [PATCH v3.1 2/4] efi/arm: preserve early mapping of UEFI memory map longer for BGRT

2018-07-12 Thread Will Deacon
On Tue, Jul 10, 2018 at 08:39:16PM +0200, Ard Biesheuvel wrote: > On 10 July 2018 at 19:57, James Morse wrote: > > Hi Ard, > > > > On 10/07/18 00:42, AKASHI Takahiro wrote: > >> From: Ard Biesheuvel > >> > >> The BGRT code validates the contents of the table against the UEFI > >> memory map, and

Re: [PATCH v2 3/4] efi/arm: map UEFI memory map earlier on boot

2018-07-06 Thread Will Deacon
Hi Akashi, On Fri, Jul 06, 2018 at 10:33:13AM +0900, AKASHI Takahiro wrote: > On Fri, Jul 06, 2018 at 09:42:28AM +0900, AKASHI Takahiro wrote: > > I almost believed that my patch#2 was just a preparatory one for patch#3 > > where arm_enable_runtime_services() is moved aggressively forward. > >

Re: [PATCH v2 3/4] efi/arm: map UEFI memory map earlier on boot

2018-07-05 Thread Will Deacon
On Thu, Jul 05, 2018 at 12:02:15PM +0100, James Morse wrote: > On 05/07/18 10:43, AKASHI Takahiro wrote: > > On Wed, Jul 04, 2018 at 08:49:32PM +0200, Ard Biesheuvel wrote: > >> On 4 July 2018 at 19:06, Will Deacon wrote: > >>> On Tue, Jun 19, 2018 at 03:44:23P

Re: [PATCH v2 3/4] efi/arm: map UEFI memory map earlier on boot

2018-07-04 Thread Will Deacon
Hi all, [Ard -- please can you look at the EFI parts of this patch] On Tue, Jun 19, 2018 at 03:44:23PM +0900, AKASHI Takahiro wrote: > Since arm_enter_runtime_services() was modified to always create a virtual > mapping of UEFI memory map in the previous patch, it is now renamed to >

Re: [PATCH] arm64/mm: Introduce a variable to hold base address of linear region

2018-06-19 Thread Will Deacon
On Tue, Jun 19, 2018 at 09:34:56AM +, Jin, Yanjiang wrote: > > On Tue, Jun 19, 2018 at 03:02:15AM +, Jin, Yanjiang wrote: > > > > You seem to be using this for user-space phys_to_virt() based on > > > > values found in /proc/iomem. This should give you what you want, and > > > > isolate

Re: [PATCH] arm64/mm: Introduce a variable to hold base address of linear region

2018-06-19 Thread Will Deacon
On Tue, Jun 19, 2018 at 03:02:15AM +, Jin, Yanjiang wrote: > > You seem to be using this for user-space phys_to_virt() based on values > > found in > > /proc/iomem. This should give you what you want, and isolate your user-space > > from the kernel's unexpected naming of variables. > > I

Re: [PATCH] arm64/mm: Introduce a variable to hold base address of linear region

2018-06-15 Thread Will Deacon
Hi Bhupesh, On Thu, Jun 14, 2018 at 11:53:53AM +0530, Bhupesh Sharma wrote: > On Wed, Jun 13, 2018 at 3:41 PM, Will Deacon wrote: > > On Wed, Jun 13, 2018 at 10:46:56AM +0530, Bhupesh Sharma wrote: > >> On Tue, Jun 12, 2018 at 3:42 PM, James Morse wrote: > >> > On

Re: [PATCH] arm64/mm: Introduce a variable to hold base address of linear region

2018-06-13 Thread Will Deacon
On Wed, Jun 13, 2018 at 10:46:56AM +0530, Bhupesh Sharma wrote: > On Tue, Jun 12, 2018 at 3:42 PM, James Morse wrote: > > On 12/06/18 09:25, Bhupesh Sharma wrote: > >> On Tue, Jun 12, 2018 at 12:23 PM, Ard Biesheuvel > >> wrote: > >>> On 12 June 2018 at 08:36, Bhupesh Sharma wrote: > The

Re: RFC on Kdump and PCIe on ARM64

2018-03-02 Thread Will Deacon
On Fri, Mar 02, 2018 at 09:12:29AM -0500, Sinan Kaya wrote: > On 3/2/2018 5:30 AM, Will Deacon wrote: > >> Do you really have to reset the IOMMU? Can you just give it new page > >> tables that start out with all IOVAs from all devices being invalid, > >> then add

Re: RFC on Kdump and PCIe on ARM64

2018-03-02 Thread Will Deacon
On Thu, Mar 01, 2018 at 06:03:03PM -0600, Bjorn Helgaas wrote: > On Thu, Mar 01, 2018 at 02:19:09PM -0500, Sinan Kaya wrote: > > On 3/1/2018 2:05 PM, Bjorn Helgaas wrote: > > > On Thu, Mar 01, 2018 at 12:44:26PM -0500, Sinan Kaya wrote: > > >> Hi, > > >> > > >> We are seeing IOMMU faults when

Re: [PATCH v34 04/14] arm64: kdump: reserve memory for crash dump kernel

2017-04-04 Thread Will Deacon
Guys, we were supposed to stop discussing this three days ago. On Tue, Apr 04, 2017 at 09:44:04AM +0200, David Woodhouse wrote: > On Tue, 2017-04-04 at 16:35 +0900, AKASHI Takahiro wrote: > > > > Because I think that people sometimes use those two interchangeably. > > So I said I would defer to

Re: [PATCHv7 00/11] CONFIG_DEBUG_VIRTUAL for arm64

2017-01-12 Thread Will Deacon
On Tue, Jan 10, 2017 at 01:35:39PM -0800, Laura Abbott wrote: > This is v7 of the patches to add CONFIG_DEBUG_VIRTUAL for arm64. This is > a simple reordering of patches from v6 per request of Will Deacon for ease > of merging support for arm which depends on this series. > > L

Re: [PATCH v29 4/9] arm64: kdump: implement machine_crash_shutdown()

2017-01-11 Thread Will Deacon
On Wed, Jan 11, 2017 at 03:36:28PM +0900, AKASHI Takahiro wrote: > On Tue, Jan 10, 2017 at 11:32:48AM +, Will Deacon wrote: > > On Wed, Dec 28, 2016 at 01:36:01PM +0900, AKASHI Takahiro wrote: > > > @@ -22,6 +25,7 @@ > > > extern const unsigned char arm64_relocate_

Re: [PATCHv6 00/11] CONFIG_DEBUG_VIRTUAL for arm64

2017-01-11 Thread Will Deacon
On Wed, Jan 04, 2017 at 02:30:50PM -0800, Florian Fainelli wrote: > On 01/04/2017 03:44 AM, Will Deacon wrote: > > On Tue, Jan 03, 2017 at 03:25:53PM -0800, Laura Abbott wrote: > >> On 01/03/2017 02:56 PM, Florian Fainelli wrote: > >>> On 01/03/2017 09:21 AM, Laura

Re: [PATCH v29 4/9] arm64: kdump: implement machine_crash_shutdown()

2017-01-10 Thread Will Deacon
On Wed, Dec 28, 2016 at 01:36:01PM +0900, AKASHI Takahiro wrote: > Primary kernel calls machine_crash_shutdown() to shut down non-boot cpus > and save registers' status in per-cpu ELF notes before starting crash > dump kernel. See kernel_kexec(). > Even if not all secondary cpus have shut down, we

Re: [PATCH v29 1/9] memblock: add memblock_cap_memory_range()

2017-01-10 Thread Will Deacon
t; parameter is of little use for this purpose.) > > Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org> > Reviewed-by: Will Deacon <will.dea...@arm.com> > Acked-by: Catalin Marinas <catalin.mari...@arm.com> > Cc: linux...@kvack.org > Cc: Andr

Re: [PATCHv6 00/11] CONFIG_DEBUG_VIRTUAL for arm64

2017-01-04 Thread Will Deacon
On Tue, Jan 03, 2017 at 03:25:53PM -0800, Laura Abbott wrote: > On 01/03/2017 02:56 PM, Florian Fainelli wrote: > > On 01/03/2017 09:21 AM, Laura Abbott wrote: > >> Happy New Year! > >> > >> This is a very minor rebase from v5. It only moves a few headers around. > >> I think this series should be

Re: [PATCH v28 0/9] arm64: add kdump support

2016-11-29 Thread Will Deacon
On Fri, Nov 25, 2016 at 04:20:40PM +, Catalin Marinas wrote: > On Thu, Nov 24, 2016 at 06:55:23PM +0900, AKASHI Takahiro wrote: > > AKASHI Takahiro (8): > > arm64: kdump: reserve memory for crash dump kernel > > memblock: add memblock_cap_memory_range() > > arm64: limit memory regions

Re: [PATCH v27 1/9] memblock: add memblock_cap_memory_range()

2016-11-17 Thread Will Deacon
Hi Akashi, On Thu, Nov 17, 2016 at 02:34:24PM +0900, AKASHI Takahiro wrote: > On Wed, Nov 16, 2016 at 04:30:15PM +, Will Deacon wrote: > > I thought limit was just a physical address, and then > > No, it's not. Quite right, it's a size. Sorry about that. > > memblock

Re: [PATCH v27 1/9] memblock: add memblock_cap_memory_range()

2016-11-16 Thread Will Deacon
Hi Akashi, On Mon, Nov 14, 2016 at 02:55:16PM +0900, AKASHI Takahiro wrote: > On Fri, Nov 11, 2016 at 11:19:04AM +0800, Dennis Chen wrote: > > On Fri, Nov 11, 2016 at 11:50:50AM +0900, AKASHI Takahiro wrote: > > > On Thu, Nov 10, 2016 at 05:27:20PM +, Will Deacon wrote: >

Re: [PATCH v27 1/9] memblock: add memblock_cap_memory_range()

2016-11-10 Thread Will Deacon
On Wed, Nov 02, 2016 at 01:51:53PM +0900, AKASHI Takahiro wrote: > Add memblock_cap_memory_range() which will remove all the memblock regions > except the range specified in the arguments. > > This function, like memblock_mem_limit_remove_map(), will not remove > memblocks with MEMMAP_NOMAP

Re: [PATCH 00/19] arm64 kexec kernel patches v13

2016-03-01 Thread Will Deacon
On Tue, Mar 01, 2016 at 05:17:55PM -0800, Geoff Levand wrote: > On Tue, 2016-03-01 at 10:54 -0700, Azriel Samson wrote: > > > We have been using the kexec/kdump patches on ARM64 and would like to > > use them from upstream. > > > > Assuming these are not going to be in Linux-4.5, a rebased set

Re: [PATCH v12 14/16] arm64: kdump: update a kernel doc

2015-12-15 Thread Will Deacon
On Tue, Nov 24, 2015 at 10:25:34PM +, Geoff Levand wrote: > From: AKASHI Takahiro > > This patch adds arch specific descriptions about kdump usage on arm64 > to kdump.txt. > > Signed-off-by: AKASHI Takahiro > --- >

Re: [PATCH v12 16/16] arm64: kdump: relax BUG_ON() if more than one cpus are still active

2015-12-15 Thread Will Deacon
On Tue, Nov 24, 2015 at 10:25:34PM +, Geoff Levand wrote: > From: AKASHI Takahiro > > We should try best in case of kdump. > So even if not all secondary cpus have shut down, we do kdump anyway. > --- > arch/arm64/kernel/machine_kexec.c | 8 +++- > 1 file

Re: [PATCH v12 08/16] arm64/kexec: Add core kexec support

2015-12-15 Thread Will Deacon
On Tue, Nov 24, 2015 at 10:25:34PM +, Geoff Levand wrote: > Add three new files, kexec.h, machine_kexec.c and relocate_kernel.S to the > arm64 architecture that add support for the kexec re-boot mechanism > (CONFIG_KEXEC) on arm64 platforms. > > Signed-off-by: Geoff Levand

Re: [PATCH v12 13/16] arm64: kdump: add kdump support

2015-12-15 Thread Will Deacon
On Tue, Nov 24, 2015 at 10:25:34PM +, Geoff Levand wrote: > From: AKASHI Takahiro > > On crash dump kernel, all the information about primary kernel's core > image is available in elf core header specified by "elfcorehdr=" boot > parameter. reserve_elfcorehdr()

Re: [PATCH v12 11/16] arm64: kdump: reserve memory for crash dump kernel

2015-12-15 Thread Will Deacon
On Tue, Nov 24, 2015 at 10:25:34PM +, Geoff Levand wrote: > From: AKASHI Takahiro > > On primary kernel, the memory region used by crash dump kernel must be > specified by "crashkernel=" boot parameter. reserve_crashkernel() > will allocate and reserve the region

Re: [PATCH v12 09/16] arm64/kexec: Add pr_devel output

2015-12-15 Thread Will Deacon
On Tue, Nov 24, 2015 at 10:25:34PM +, Geoff Levand wrote: > To aid in debugging kexec problems or when adding new functionality to kexec > add > a new routine kexec_image_info() and several inline pr_devel statements. We don't currently have any pr_devel invocations under arm64. Can you

Re: [PATCH v12 04/16] arm64: kvm: allows kvm cpu hotplug

2015-12-11 Thread Will Deacon
On Thu, Dec 10, 2015 at 10:31:48AM -0800, Geoff Levand wrote: > On Thu, 2015-12-03 at 13:58 +, Marc Zyngier wrote: > > Indeed, this is completely broken (I just reproduced the issue on a > > model). > > There are users out there that want kexec/kdump support. I think we > should remove this

Re: [PATCH v12 05/16] arm64: Add back cpu_reset routines

2015-12-10 Thread Will Deacon
On Wed, Dec 09, 2015 at 04:49:22PM -0800, Geoff Levand wrote: > On Thu, 2015-12-03 at 09:32 +, Will Deacon wrote: > > On Wed, Dec 02, 2015 at 02:57:30PM -0800, Geoff Levand wrote: > > > On Mon, 2015-11-30 at 10:40 +, Marc Zyngier wrote: > > > > >

Re: [PATCH v12 05/16] arm64: Add back cpu_reset routines

2015-12-03 Thread Will Deacon
On Wed, Dec 02, 2015 at 02:57:30PM -0800, Geoff Levand wrote: > On Mon, 2015-11-30 at 10:40 +, Marc Zyngier wrote: > > > All that can be solved in C, and mostly at compile time. Using an > > assembler trampoline is complicating things for no good reason: > > I added this into my kexec-v12.1

Re: [PATCH 11/15] arm64: kdump: implement machine_crash_shutdown()

2015-11-10 Thread Will Deacon
On Tue, Nov 10, 2015 at 10:23:56AM +0900, AKASHI Takahiro wrote: > On 11/07/2015 04:14 AM, Geoff Levand wrote: > >From: AKASHI Takahiro > > > >kdump calls machine_crash_shutdown() to shut down non-boot cpus and > >save registers' status in per-cpu ELF notes before

Re: [PATCH 01/10] arm64/kvm: Fix assembler compatibility of macros

2014-10-27 Thread Will Deacon
On Fri, Oct 24, 2014 at 10:24:51AM +0100, Mark Rutland wrote: On Fri, Oct 24, 2014 at 12:10:58AM +0100, Geoff Levand wrote: Some of the macros defined in kvm_arm.h are useful in assembly files, but are not compatible with the assembler. Change any C language integer constant definitions

Re: [PATCH 0/7] arm64 kexec kernel patches V3

2014-10-09 Thread Will Deacon
On Thu, Sep 25, 2014 at 01:23:26AM +0100, Geoff Levand wrote: Hi All, Hi Geoff, This series adds the core support for kexec re-boots on arm64. I have tested with the ARM VE fast model using various kernel config options for both the first and second stage kernels. To load a second stage

Re: [PATCH 04/13] arm64: Add new hcall HVC_CALL_FUNC

2014-09-10 Thread Will Deacon
On Wed, Sep 10, 2014 at 06:23:57PM +0100, Geoff Levand wrote: On Wed, 2014-09-10 at 18:07 +0100, Will Deacon wrote: On Tue, Sep 09, 2014 at 11:49:04PM +0100, Geoff Levand wrote: diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S index 9ab5f70..a21cf51 100644

Re: [PATCH RESEND] ARM: kdump: 2nd kernel should use strict pfn_valid in SPARSEMEM platform

2014-05-29 Thread Will Deacon
On Thu, May 29, 2014 at 05:54:02AM +0100, AKASHI Takahiro wrote: Catalin, Will Can we assume that HAVE_ARCH_PFN_VALID is alway yes on arm64? Looking at arm64/Kconfig, config ARCH_HAS_HOLES_MEMORYMODEL def_bool y if SPARSEMEM ... config HAVE_ARCH_PFN_VALID def_bool

Re: [PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid

2014-05-19 Thread Will Deacon
On Mon, May 19, 2014 at 02:54:03AM +0100, Wang Nan wrote: When SPARSEMEM and CRASH_DUMP both selected, simple pfn_valid prevents the second kernel ioremap first kernel's memory if the address falls into second kernel section. This limitation requires the second kernel occupies a full section,

Re: [PATCH 2/3] ARM : kdump : add arch_crash_save_vmcoreinfo

2014-04-14 Thread Will Deacon
-by: Will Deacon will.dea...@arm.com Will Signed-off-by: Liu Hua sdu@huawei.com To: Russell King li...@arm.linux.org.uk Cc: Stephen Warren swar...@nvidia.com Cc: Will Deacon will.dea...@arm.com Cc: Vijaya Kumar K vijay.kil...@gmail.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux

Re: [PATCH 2/3] ARM : kdump : add arch_crash_save_vmcoreinfo

2014-04-14 Thread Will Deacon
On Mon, Apr 14, 2014 at 01:41:34PM +0100, Liu hua wrote: 于 2014/4/14 19:37, Will Deacon 写道: On Thu, Mar 27, 2014 at 08:00:39AM +, Liu Hua wrote: For vmcore generated by LPAE enabled kernel, user space utility such as crash needs additional infomation to parse. So this patch add

Re: [PATCH 1/3] ARM: Premit ioremap() to map reserved pages

2014-01-22 Thread Will Deacon
On Wed, Jan 22, 2014 at 11:25:14AM +, Wang Nan wrote: This patch relaxes the restriction set by commit 309caa9cc, which prohibit ioremap() on all kernel managed pages. Other architectures, such as x86 and (some specific platforms of) powerpc, allow such mapping. ioremap() pages is an

Re: [PATCH] ARM: call disable_nonboot_cpus() from machine_shutdown()

2013-01-07 Thread Will Deacon
Hi Eric, On Mon, Jan 07, 2013 at 01:53:30AM +, Eric W. Biederman wrote: Russell King - ARM Linux li...@arm.linux.org.uk writes: The problem is... on ARM we're yet again shot in the foot through the unwillingness to architect certain aspects of the system: there is no architecturally

Re: [PATCH] ARM: call disable_nonboot_cpus() from machine_shutdown()

2013-01-06 Thread Will Deacon
On Thu, Jan 03, 2013 at 08:26:15PM +, Stephen Warren wrote: On 01/03/2013 05:21 AM, Russell King - ARM Linux wrote: On Thu, Jan 03, 2013 at 12:02:59PM +, Will Deacon wrote: You need the smp_send_stop call in order to send the cpu_kill (looks like tegra needs die and then kill). So

  1   2   >