[PATCH v2] kexec: copy only happens before uchunk goes to zero

From: "yang.zhang" When load segments, all of the copying and the rest only happens before uchunk goes to zero. Signed-off-by: yang.zhang --- v1 -> v2: - Only copy before uchunk goes to zero V1: https://lore.kernel.org/lkml/20240130101802.23850-1-gaoshanliu...@163.com/ ---

[PATCH 2/2] x86/snp: Convert shared memory back to private on kexec

From: Ashish Kalra SNP 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 this way. It only sees E820_TYPE_RAM.

[PATCH 0/2] x86/snp: Add kexec support

From: Ashish Kalra The patchset adds bits and pieces to get kexec (and crashkernel) work on SNP guest. This patchset requires [1] for chained guest kexec to work correctly. [1]: https://lore.kernel.org/lkml/20240219225451.787816-1-ashish.ka...@amd.com/ Ashish Kalra (2): x86/mm: Do not zap

[PATCH 1/2] x86/mm: Do not zap PMD entry mapping unaccepted memory table during kdump.

From: Ashish Kalra During crashkernel boot only pre-allocated crash memory is presented as E820_TYPE_RAM. This can cause PMD entry mapping unaccepted memory table to be zapped during phys_pmd_init() as SNP/TDX guest use E820_TYPE_ACPI to store the unaccepted memory table and pass it between the

[PATCH v2] efi/x86: skip efi_arch_mem_reserve() in case of kexec.

From: Ashish Kalra For kexec use case, need to use and stick to the EFI memmap passed from the first kernel via boot-params/setup data, hence, skip efi_arch_mem_reserve() during kexec. Additionally during SNP guest kexec testing discovered that EFI memmap is corrupted during chained kexec.

Re: [PATCH v5 1/8] ima: define and call ima_alloc_kexec_file_buf

On 2/14/24 10:38, Tushar Sugandhi wrote: Carrying the IMA measurement list across kexec requires allocating a buffer and copying the measurement records. Separate allocating the buffer and copying the measurement records into separate functions in order to allocate the buffer at kexec 'load'

[PATCH] efi/x86: skip efi_arch_mem_reserve() in case of kexec.

From: Ashish Kalra For kexec use case, need to use and stick to the EFI memmap passed from the first kernel via boot-params/setup data, hence, skip efi_arch_mem_reserve() during kexec. Additionally during SNP guest kexec testing discovered that EFI memmap is corrupted during chained kexec.

Re: [PATCHv7 07/16] x86/mm: Return correct level from lookup_address() if pte is none

On Mon, Feb 19, 2024 at 01:12:32PM +0800, Baoquan He wrote: > On 02/12/24 at 12:44pm, Kirill A. Shutemov wrote: > > lookup_address() only returns correct page table level for the entry if > > the entry is not none. > > > > Make the helper to always return correct 'level'. It allows to implement >

Re: [PATCHv7 01/16] x86/acpi: Extract ACPI MADT wakeup code into a separate file

On 02/19/24 at 12:08pm, Kirill A. Shutemov wrote: > On Mon, Feb 19, 2024 at 12:45:31PM +0800, Baoquan He wrote: > > Do we need add the entry printing for ACPI_MADT_TYPE_MULTIPROC_WAKEUP > > now in acpi_table_print_madt_entry()? Surely it's not related to this > > patch. > > Good catch. See patch

Re: [PATCHv7 01/16] x86/acpi: Extract ACPI MADT wakeup code into a separate file

On Mon, Feb 19, 2024 at 12:45:31PM +0800, Baoquan He wrote: > Do we need add the entry printing for ACPI_MADT_TYPE_MULTIPROC_WAKEUP > now in acpi_table_print_madt_entry()? Surely it's not related to this > patch. Good catch. See patch below. Does it look okay? > FWIW, > > Reviewed-by: Baoquan

Re:Re: [PATCH] kexec: should use uchunk for user buffer increasing

Thanks, i would post v2 patch. Could you please provide the email address for andrew. At 2024-02-19 10:38:22, "Baoquan He" wrote: >On 02/19/24 at 10:00am, yang.zhang wrote: >> >> >> >> Thanks for your replies. >> Do you have plans to merge the improving code for clarity, or just