Re: [PATCH 2/2] support kdump when AMD secure memory encryption is active

On 5/14/2018 8:51 PM, Lianbo Jiang wrote: > When sme enabled on AMD server, we also need to support kdump. Because > the memory is encrypted in the first kernel, we will remap the old memory > encrypted to the second kernel(crash kernel), and sme is also enabled in > the second kernel, otherwise

Re: [PATCH v9 06/11] arm64: kexec_file: allow for loading Image-format kernel

Hi Akashi, On 15/05/18 06:13, AKASHI Takahiro wrote: > On Fri, May 11, 2018 at 06:07:06PM +0100, James Morse wrote: >> On 07/05/18 08:21, AKASHI Takahiro wrote: >>> On Tue, May 01, 2018 at 06:46:11PM +0100, James Morse wrote: On 25/04/18 07:26, AKASHI Takahiro wrote: > This patch

Re: [PATCH v9 07/11] arm64: kexec_file: add crash dump support

Hi guys, (CC: +RobH, devicetree list) On 25/04/18 07:26, AKASHI Takahiro wrote: > Enabling crash dump (kdump) includes > * prepare contents of ELF header of a core dump file, /proc/vmcore, > using crash_prepare_elf64_headers(), and > * add two device tree properties,

Re: [PATCH v9 07/11] arm64: kexec_file: add crash dump support

Hi Akashi, On 25/04/18 07:26, AKASHI Takahiro wrote: > Enabling crash dump (kdump) includes > * prepare contents of ELF header of a core dump file, /proc/vmcore, > using crash_prepare_elf64_headers(), and > * add two device tree properties, "linux,usable-memory-range" and >

Re: [PATCH v9 05/11] arm64: kexec_file: load initrd and device-tree

Hi Akashi, On 25/04/18 07:26, AKASHI Takahiro wrote: > load_other_segments() is expected to allocate and place all the necessary > memory segments other than kernel, including initrd and device-tree > blob (and elf core header for crash). > While most of the code was borrowed from kexec-tools'

Re: [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list

Hi Akashi, On 15/05/18 05:35, AKASHI Takahiro wrote: > On Mon, May 07, 2018 at 02:59:07PM +0900, AKASHI Takahiro wrote: >> On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote: >>> On 25/04/18 07:26, AKASHI Takahiro wrote: We need to prevent firmware-reserved memory regions,

Re: [PATCH v9 03/11] arm64: kexec_file: invoke the kernel without purgatory

Hi Akashi, On 15/05/18 05:45, AKASHI Takahiro wrote: > On Fri, May 11, 2018 at 06:03:49PM +0100, James Morse wrote: >> On 07/05/18 06:22, AKASHI Takahiro wrote: >>> On Tue, May 01, 2018 at 06:46:06PM +0100, James Morse wrote: On 25/04/18 07:26, AKASHI Takahiro wrote: > diff --git

Re: [PATCH 1/2] add a function(ioremap_encrypted) for kdump when AMD sme enabled.

On 5/14/2018 8:51 PM, Lianbo Jiang wrote: > It is convenient to remap the old memory encrypted to the second kernel > by calling ioremap_encrypted(). > > Signed-off-by: Lianbo Jiang > --- > arch/x86/include/asm/io.h | 2 ++ > arch/x86/mm/ioremap.c | 25

Re: [PATCH 0/2] support kdump for AMD secure memory encryption(sme)

On 5/14/2018 8:51 PM, Lianbo Jiang wrote: > It is convenient to remap the old memory encrypted to the second kernel by > calling ioremap_encrypted(). > > When sme enabled on AMD server, we also need to support kdump. Because > the memory is encrypted in the first kernel, we will remap the old

Re: [PATCH 2/2] support kdump when AMD secure memory encryption is active

: https://github.com/0day-ci/linux/commits/Lianbo-Jiang/support-kdump-for-AMD-secure-memory-encryption-sme/20180515-135732 reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed

Re: [PATCH 0/2] Remove obsolete kdump tool and add missing uninstall rule

Hello Russell, Simon, On Mon, Apr 23, 2018 at 10:30 AM, Bhupesh Sharma wrote: > This patchset contains two patches: > > [1/2] - Adds a missing uninstall rule to 'Makefile.in' to allow easier > uninstallation of executables and man pages installed via > 'make

Re: [PATCH v2] arm64: Add support to supply 'kaslr-seed' to secondary kernel

Hello Akashi, On Thu, Apr 26, 2018 at 2:27 PM, Bhupesh Sharma wrote: > This patch adds the support to supply 'kaslr-seed' to secondary kernel, > when we do a 'kexec warm reboot to another kernel' (although the > behaviour remains the same for the 'kdump' case as well) on