Re: [PATCH 2/2] Remove the memory encryption mask to obtain the true physical address

+ Tom On 01/25/19 at 11:06am, lijiang wrote: > 在 2019年01月24日 06:16, Kazuhito Hagio 写道: > > On 1/22/2019 3:03 AM, Lianbo Jiang wrote: > >> For AMD machine with SME feature, if SME is enabled in the first > >> kernel, the crashed kernel's page table(pgd/pud/pmd/pte) contains > >> the memory encryptio

Re: [PATCH 2/2] Remove the memory encryption mask to obtain the true physical address

在 2019年01月25日 03:33, Kazuhito Hagio 写道: > On 1/23/2019 5:16 PM, Kazuhito Hagio wrote: >> On 1/22/2019 3:03 AM, Lianbo Jiang wrote: >>> For AMD machine with SME feature, if SME is enabled in the first >>> kernel, the crashed kernel's page table(pgd/pud/pmd/pte) contains >>> the memory encryption mas

Re: [PATCH 2/2] Remove the memory encryption mask to obtain the true physical address

在 2019年01月24日 06:16, Kazuhito Hagio 写道: > On 1/22/2019 3:03 AM, Lianbo Jiang wrote: >> For AMD machine with SME feature, if SME is enabled in the first >> kernel, the crashed kernel's page table(pgd/pud/pmd/pte) contains >> the memory encryption mask, so makedumpfile needs to remove the >> memory e

Re: [PATCH v3 1/3] x86, kexec_file_load: Don't setup EFI info if EFI runtime is not enabled

On 01/18/19 at 07:13pm, Kairui Song wrote: > Currently with "efi=noruntime" in kernel command line, calling > kexec_file_load will raise below problem: > > [ 97.967067] BUG: unable to handle kernel NULL pointer dereference at > > [ 97.967894] #PF error: [normal kernel read fa

[PATCH RESEND 3/3] x86/kdump/64: Change the upper limit of crashkernel reservation

Restrict kdump to only reserve crashkernel below 64TB. Since the kdump jumping may be from 5-level to 4-level, and the kdump kernel is put above 64TB in 5-level kernel, then the jumping will fail. And the crashkernel reservation is done during the 1st kernel bootup, there's no way to detect the pag

[PATCH RESEND 2/3] x86/kexec/64: Error out if try to jump to old 4-level kernel from 5-level kernel

In relocate_kernel() CR4.LA57 flag is set before kexec jumping if the kernel has 5-level paging enabled. Then in boot/compressed/head_64.S, it will check if the booting kernel is in 4-level or 5-level paging mode, and handle accordingly. However, the old kernel which doesn't contain the 5-level cod

[PATCH RESEND 0/3] Add restrictions for kexec/kdump jumping between 5-level and 4-level kernel

This is a RESEND post. The original v1 post can be found here: http://lkml.kernel.org/r/20180829141624.13985-1-...@redhat.com It's trying to fix several corner case issues for kexec/kdump when dynamic switching of paging mode is enabled in x86_64. Please click above link to check the details. I

[PATCH RESEND 1/3] x86/boot: Add bit fields into xloadflags for 5-level kernel checking

Add two bit fields XLF_5LEVEL and XLF_5LEVEL_ENABLED for 5-level kernel. Bit XLF_5LEVEL indicates if 5-level related code is contained in this kernel. Bit XLF_5LEVEL_ENABLED indicates if CONFIG_X86_5LEVEL=y is set. They are being used in later patch to check if kexec/kdump kernel is loaded in righ

RE: [PATCH 2/2] Remove the memory encryption mask to obtain the true physical address

On 1/23/2019 5:16 PM, Kazuhito Hagio wrote: > On 1/22/2019 3:03 AM, Lianbo Jiang wrote: > > For AMD machine with SME feature, if SME is enabled in the first > > kernel, the crashed kernel's page table(pgd/pud/pmd/pte) contains > > the memory encryption mask, so makedumpfile needs to remove the > >

Re: [PATCH 1/2] Makedumpfile: add a new variable 'sme_mask' to number_table

在 2019年01月24日 05:51, Kazuhito Hagio 写道: > Hi Lianbo, > > On 1/22/2019 3:03 AM, Lianbo Jiang wrote: >> It will be used to store the sme mask for crashed kernel, the >> sme_mask denotes whether the old memory is encrypted or not. >> >> Signed-off-by: Lianbo Jiang >> --- >> makedumpfile.c | 3 +++ >