Re: [PATCH v2 2/4] efi/arm: map UEFI memory map even w/o runtime services enabled

2018-06-28 Thread James Morse
Hi Akashi, On 19/06/18 07:44, AKASHI Takahiro wrote: > Under the current implementation, UEFI memory map will be mapped and made > available in virtual mappings only if runtime services are enabled. > But in a later patch, we want to use UEFI memory map in acpi_os_ioremap() > to create mappings

Re: [PATCH v2 4/4] arm64: acpi: fix alignment fault in accessing ACPI

2018-06-28 Thread James Morse
Hi Akashi, On 19/06/18 07:44, AKASHI Takahiro wrote: > This is a fix against the issue that crash dump kernel may hang up > during booting, which can happen on any ACPI-based system with "ACPI > Reclaim Memory." > > (kernel messages after panic kicked off kdump) > (snip...) > Bye!

Re: [PATCH 5/5 V4] Help to dump the old memory encrypted into vmcore file

2018-06-28 Thread kbuild test robot
Hi Lianbo, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.18-rc2 next-20180628] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

Re: [PATCH 5/5 V4] Help to dump the old memory encrypted into vmcore file

2018-06-28 Thread kbuild test robot
Hi Lianbo, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.18-rc2 next-20180628] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

[PATCH 5/5 V4] Help to dump the old memory encrypted into vmcore file

2018-06-28 Thread Lianbo Jiang
In kdump mode, we need to dump the old memory into vmcore file, if SME is enabled in the first kernel, we must remap the old memory in encrypted manner, which will be automatically decrypted when we read from DRAM. It helps to parse the vmcore for some tools. Signed-off-by: Lianbo Jiang --- Some

[PATCH 4/5 V4] Adjust some permanent mappings in unencrypted ways for kdump when SME is enabled.

2018-06-28 Thread Lianbo Jiang
For kdump, the acpi table and dmi table will need to be remapped in unencrypted ways during early init, they have just a simple wrapper around early_memremap(), but the early_memremap() remaps the memory in encrypted ways by default when SME is enabled, so we put some logic into the

[PATCH 0/5 V4] Support kdump for AMD secure memory encryption(SME)

2018-06-28 Thread Lianbo Jiang
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 the old memory encrypted can not be decrypted.

[PATCH 3/5 V4] Remap the device table of IOMMU in encrypted manner for kdump

2018-06-28 Thread Lianbo Jiang
In kdump mode, it will copy the device table of IOMMU from the old device table, which is encrypted when SME is enabled in the first kernel. So we must remap it in encrypted manner in order to be automatically decrypted when we read. Signed-off-by: Lianbo Jiang --- Some changes: 1. add some

[PATCH 1/5 V4] Add a function(ioremap_encrypted) for kdump when AMD sme enabled

2018-06-28 Thread Lianbo Jiang
It is convenient to remap the old memory encrypted to the second kernel by calling ioremap_encrypted(). Signed-off-by: Lianbo Jiang --- Some changes: 1. remove the sme_active() check in __ioremap_caller(). 2. revert some logic in the early_memremap_pgprot_adjust() for early memremap and make it

[PATCH 2/5 V4] Allocate pages for kdump without encryption when SME is enabled

2018-06-28 Thread Lianbo Jiang
When SME is enabled in the first kernel, we will allocate pages for kdump without encryption in order to be able to boot the second kernel in the same manner as kexec, which helps to keep the same code style. Signed-off-by: Lianbo Jiang --- Some changes: 1. remove some redundant codes for crash