Re: [PATCH v6 (proposal)] powerpc/cpu: enable nr_cpus for crash kernel

2024-01-29 Thread Pingfan Liu
Hi Christophe, The latest series is https://lore.kernel.org/linuxppc-dev/20231017022806.4523-1-pi...@redhat.com/ And Michael has his implement on: https://lore.kernel.org/all/20231229120107.2281153-3-...@ellerman.id.au/T/#m46128446bce1095631162a1927415733a3bf0633 Thanks, Pingfan On Fri, Jan

RE: [PATCH v2 linux-next 1/3] x86, crash: don't nest CONFIG_CRASH_DUMP ifdef inside CONFIG_KEXEC_CODE ifdef scope

2024-01-29 Thread Michael Kelley
From: Baoquan He Sent: Monday, January 29, 2024 7:00 PM > > Michael pointed out that the CONFIG_CRASH_DUMP ifdef is nested inside > CONFIG_KEXEC_CODE ifdef scope in some XEN, Hyper-V codes. > > Although the nesting works well too since CONFIG_CRASH_DUMP has > dependency on CONFIG_KEXEC_CORE, it

Re: [PATCH linux-next 1/3] x86, crash: don't nest CONFIG_CRASH_DUMP ifdef inside CONFIG_KEXEC_CODE ifdef scope

2024-01-29 Thread Baoquan He
On 01/30/24 at 01:39am, Michael Kelley wrote: > From: Baoquan He > > > > On 01/29/24 at 06:27pm, Michael Kelley wrote: > > > From: Baoquan He Sent: Monday, January 29, 2024 > > 5:51 AM > > > > > > > > Michael pointed out that the #ifdef CONFIG_CRASH_DUMP is nested inside > > > >

Re: [PATCH v2 linux-next 1/3] x86, crash: don't nest CONFIG_CRASH_DUMP ifdef inside CONFIG_KEXEC_CODE ifdef scope

2024-01-29 Thread Baoquan He
Michael pointed out that the CONFIG_CRASH_DUMP ifdef is nested inside CONFIG_KEXEC_CODE ifdef scope in some XEN, Hyper-V codes. Although the nesting works well too since CONFIG_CRASH_DUMP has dependency on CONFIG_KEXEC_CORE, it may cause confusion because there are places where it's not nested,

RE: [PATCH linux-next 1/3] x86, crash: don't nest CONFIG_CRASH_DUMP ifdef inside CONFIG_KEXEC_CODE ifdef scope

2024-01-29 Thread Michael Kelley
From: Baoquan He > > On 01/29/24 at 06:27pm, Michael Kelley wrote: > > From: Baoquan He Sent: Monday, January 29, 2024 > 5:51 AM > > > > > > Michael pointed out that the #ifdef CONFIG_CRASH_DUMP is nested inside > > > arch/x86/xen/enlighten_hvm.c. > > > > Did some words get left out in the

Re: [PATCH linux-next 1/3] x86, crash: don't nest CONFIG_CRASH_DUMP ifdef inside CONFIG_KEXEC_CODE ifdef scope

2024-01-29 Thread Baoquan He
On 01/29/24 at 06:27pm, Michael Kelley wrote: > From: Baoquan He Sent: Monday, January 29, 2024 5:51 AM > > > > Michael pointed out that the #ifdef CONFIG_CRASH_DUMP is nested inside > > arch/x86/xen/enlighten_hvm.c. > > Did some words get left out in the above sentence? It mentions the Xen >

RE: [PATCH linux-next 1/3] x86, crash: don't nest CONFIG_CRASH_DUMP ifdef inside CONFIG_KEXEC_CODE ifdef scope

2024-01-29 Thread Michael Kelley
From: Baoquan He Sent: Monday, January 29, 2024 5:51 AM > > Michael pointed out that the #ifdef CONFIG_CRASH_DUMP is nested inside > arch/x86/xen/enlighten_hvm.c. Did some words get left out in the above sentence? It mentions the Xen case, but not the Hyper-V case. I'm not sure what you

Re: [PATCH v3 00/17] kexec: Allow preservation of ftrace buffers

2024-01-29 Thread Philipp Rudo
Hi Alex, adding linux-integrity as there are some synergies with IMA_KEXEC (in case we get KHO to work). Fist of all I believe that having a generic framework to pass information from one kernel to the other across kexec would be a good thing. But I'm afraid that you are ignoring some

[PATCH linux-next 3/3] arch, crash: move arch_crash_save_vmcoreinfo() out to file vmcore_info.c

2024-01-29 Thread Baoquan He
Nathan reported below building error: = $ curl -LSso .config https://git.alpinelinux.org/aports/plain/community/linux-edge/config-edge.armv7 $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- olddefconfig all ... arm-linux-gnueabi-ld: arch/arm/kernel/machine_kexec.o: in function

[PATCH linux-next 1/3] x86, crash: don't nest CONFIG_CRASH_DUMP ifdef inside CONFIG_KEXEC_CODE ifdef scope

2024-01-29 Thread Baoquan He
Michael pointed out that the #ifdef CONFIG_CRASH_DUMP is nested inside arch/x86/xen/enlighten_hvm.c. Although the nesting works well too since CONFIG_CRASH_DUMP has dependency on CONFIG_KEXEC_CORE, it may cause confuse because there are places where it's not nested, and people may think it need

[PATCH linux-next 2/3] crash: fix building error in generic codes

2024-01-29 Thread Baoquan He
Nathan reported some building errors on arm64 as below: == $ curl -LSso .config https://github.com/archlinuxarm/PKGBUILDs/raw/master/core/linux-aarch64/config $ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux- olddefconfig all ... aarch64-linux-ld: kernel/kexec_file.o: in

Re: [PATCHv6 10/16] x86/tdx: Convert shared memory back to private on kexec

2024-01-29 Thread Kirill A. Shutemov
On Mon, Jan 29, 2024 at 07:09:37AM -0600, Kalra, Ashish wrote: > Hello Kirill, > > On 1/29/2024 4:36 AM, Kirill A. Shutemov wrote: > > On Mon, Jan 29, 2024 at 04:24:09AM -0600, Kalra, Ashish wrote: > > > In case of SNP and crash/kdump case, we need to prevent the boot_ghcb > > > being > > >

Re: [PATCHv6 10/16] x86/tdx: Convert shared memory back to private on kexec

2024-01-29 Thread Kalra, Ashish
Hello Kirill, On 1/29/2024 4:36 AM, Kirill A. Shutemov wrote: On Mon, Jan 29, 2024 at 04:24:09AM -0600, Kalra, Ashish wrote: In case of SNP and crash/kdump case, we need to prevent the boot_ghcb being converted to shared (in snp_kexec_unshare_mem()) as the boot_ghcb is required to handle all

Re: [PATCHv6 10/16] x86/tdx: Convert shared memory back to private on kexec

2024-01-29 Thread Kirill A. Shutemov
On Mon, Jan 29, 2024 at 04:24:09AM -0600, Kalra, Ashish wrote: > In case of SNP and crash/kdump case, we need to prevent the boot_ghcb being > converted to shared (in snp_kexec_unshare_mem()) as the boot_ghcb is > required to handle all I/O for disabling IO-APIC/lapic, hpet, etc., as the >

Re: [PATCHv6 10/16] x86/tdx: Convert shared memory back to private on kexec

2024-01-29 Thread Kalra, Ashish
Hello Kirill, On 1/24/2024 6:55 AM, Kirill A. Shutemov wrote: TDX guests allocate shared buffers to perform I/O. It is done by allocating pages normally from the buddy allocator and converting them to shared with set_memory_decrypted(). The second kernel has no idea what memory is converted