On Tue, 5 Mar 2024 at 09:32, Dave Young wrote:
>
> crashkernel reservation failed on a Thinkpad t440s laptop recently,
> Actually the memblock reservation succeeded, but later insert_resource()
> failed.
>
> Test step:
> kexec load ->
> kexec reboot ->
> check the
Hi,
Added Ard in cc.
On 03/18/24 at 07:02am, Ashish Kalra wrote:
> 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
Hi,
On 03/18/24 at 12:00pm, chenhaixiang (A) wrote:
> Dear kexec Community Members,
>
> I encountered an issue while using kexec-tools on my x86_64 machine.
> When there is a segment marked as 'reserved' within the memory range
> allocated for the crash kernel in /proc/iomem,the output appears
On 3/17/24 11:52 PM, Hari Bathini wrote:
Just checking on whether this will go via bpf or mm tree?
Sending to bpf-next should be okay.
Could you resubmit the patch as CONFIG_CRASH_DUMP probably not
available to bpf-next when you initially submitted the patch.
On 09/02/24 6:05 pm, Hari
Dear kexec Community Members,
I encountered an issue while using kexec-tools on my x86_64 machine.
When there is a segment marked as 'reserved' within the memory range allocated
for the crash kernel in /proc/iomem,the output appears as follows:
2d4fd058-60efefff : System RAM
2d4fd058-58ff
On 18/03/24 14:18, HAGIO KAZUHITO(萩尾 一仁) wrote:
On 2024/03/18 17:26, Aditya Gupta wrote:
Hi,
The commit removing 'vmap_area_list' is now merged in Linux mainline tree.
commit: 55c49fee57af99f3c663e69dedc5b85e691bbe50
mm/vmalloc: remove vmap_area_list
Applied with this commit
On 2024/03/18 17:26, Aditya Gupta wrote:
> Hi,
> The commit removing 'vmap_area_list' is now merged in Linux mainline tree.
> commit: 55c49fee57af99f3c663e69dedc5b85e691bbe50
> mm/vmalloc: remove vmap_area_list
Applied with this commit id and the fix.
Hi,
The commit removing 'vmap_area_list' is now merged in Linux mainline tree.
commit: 55c49fee57af99f3c663e69dedc5b85e691bbe50
mm/vmalloc: remove vmap_area_list
Any comments on this patch ?
Thanks,
Aditya Gupta
On 24/02/24 00:33, Aditya Gupta wrote:
Below error was noticed when
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.
From: Ashish Kalra
During crashkernel boot only pre-allocated crash memory is presented as
E820_TYPE_RAM. This can cause page table entries mapping unaccepted memory
table to be zapped during phys_pte_init(), phys_pmd_init(), phys_pud_init()
and phys_p4d_init() as SNP/TDX guest use
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.
From: Ashish Kalra
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
v2:
- address zeroing of unaccepted memory table mappings at all page table levels
adding phys_pte_init(), phys_pud_init() and phys_p4d_init().
- include skip efi_arch_mem_reserve() in case
Just checking on whether this will go via bpf or mm tree?
On 09/02/24 6:05 pm, Hari Bathini wrote:
With [1], CONFIG_KEXEC & !CONFIG_CRASH_DUMP is supported but that led
to the below warning:
"WARN: resolve_btfids: unresolved symbol crash_kexec"
Fix it by using the appropriate #ifdef.
[1]
13 matches
Mail list logo
