On 2024/04/24 11:20, Coiby Xu wrote:
> Fedora is going unify bin and sbin and /usr/sbin directory will become a
> symlink to bin [1]. So make sbindir configurable to support this case.
>
> [1] https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
>
> Signed-off-by: Coiby Xu
Thank you for
Commit 247262756121 ("crash: add generic infrastructure for crash
hotplug support") added a generic infrastructure that allows
architectures to selectively update the kdump image component during CPU
or memory add/remove events within the kernel itself.
This patch series adds crash hotplug
In the event of memory hotplug or online/offline events, the crash
memory hotplug notifier `crash_memhp_notifier()` receives a
`memory_notify` object but doesn't forward that object to the
generic and architecture-specific crash hotplug handler.
The `memory_notify` object contains the starting
Commit a72bbec70da2 ("crash: hotplug support for kexec_load()")
introduced a new kexec flag, `KEXEC_UPDATE_ELFCOREHDR`. Kexec tool uses
this flag to indicate to the kernel that it is safe to modify the
elfcorehdr of the kdump image loaded using the kexec_load system call.
However, it is possible
Due to CPU/Memory hotplug or online/offline events, the elfcorehdr
(which describes the CPUs and memory of the crashed kernel) and FDT
(Flattened Device Tree) of kdump image becomes outdated. Consequently,
attempting dump collection with an outdated elfcorehdr or FDT can lead
to failed or
Move the following functions form kexec/{file_load_64.c => ranges.c} and
make them public so that components other than KEXEC_FILE can also use
these functions.
1. get_exclude_memory_ranges
2. get_reserved_memory_ranges
3. get_crash_memory_ranges
4. get_usable_memory_ranges
Later in the series
Move the update_cpus_node() from kexec/{file_load_64.c => core_64.c}
to allow other kexec components to use it.
Later in the series, this function is used for in-kernel updates
to the kdump image during CPU/memory hotplug or online/offline events for
both kexec_load and kexec_file_load syscalls.
Extend the arch crash hotplug handler, as introduced by the patch title
("powerpc: add crash CPU hotplug support"), to also support memory
add/remove events.
Elfcorehdr describes the memory of the crash kernel to capture the
kernel; hence, it needs to be updated if memory resources change due to
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.
On Fri, Apr 26, 2024 at 09:47:02AM -0500, Kalra, Ashish wrote:
> I should have mentioned *chained* guest kexec above instead of nested guest
> kexec.
What is a "chained guest kexec" now?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 4/26/2024 10:34 AM, Borislav Petkov wrote:
On Fri, Apr 26, 2024 at 10:28:41AM -0500, Kalra, Ashish wrote:
"Chained guest kexec" is when we are in a guest and kexec-ing into a new
kernel and then this kernel kexecs into another and so on ...
Make sure to explain your terminology:
$ git
From: Ashish Kalra
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
The series is based off of and tested against Kirill Shutemov's tree:
https://github.com/intel/tdx.git guest-kexec
v6:
- Updated and restructured the commit message for patch 1/3 to
From: Ashish Kalra
With SNP guest kexec observe the following efi memmap corruption :
[0.00] efi: EFI v2.7 by EDK II
[0.00] efi: SMBIOS=0x7e33f000 SMBIOS 3.0=0x7e33d000 ACPI=0x7e57e000
ACPI 2.0=0x7e57e014 MEMATTR=0x7cc3c018 Unaccepted=0x7c09e018
[0.00] efi: [Firmware
From: Ashish Kalra
Accessing guest video memory/RAM during kernel decompressor
causes guest termination as boot stage2 #VC handler for
SEV-ES/SNP systems does not support MMIO handling.
This issue is observed with SEV-ES/SNP guest kexec as
kexec -c adds screen_info to the boot parameters
passed
On Wed, Apr 24, 2024 at 02:17:27PM +0200, Alexander Kanavin wrote:
> From: Haiqing Bai
>
> When "CONFIG_ARM_LPAE" is enabled,3 level page table
> is used by MMU, the "SECTION_SIZE" is defined with
> (1 << 21), but 'add_buffer_phys_virt()' hardcode this
> to (1 << 20).
>
> Suggested-By:
On Fri, Apr 26, 2024 at 10:28:41AM -0500, Kalra, Ashish wrote:
> "Chained guest kexec" is when we are in a guest and kexec-ing into a new
> kernel and then this kernel kexecs into another and so on ...
Make sure to explain your terminology:
$ git grep -rE "chained.*kexec"
$
and there's nothing
On 4/26/2024 9:21 AM, Borislav Petkov wrote:
On Wed, Apr 24, 2024 at 04:17:09PM -0500, Kalra, Ashish wrote:
With SNP guest kexec and during nested guest kexec, observe the following
efi memmap corruption :
Before we delve any deeper here, lemme make sure I understand this
correctly:
* You're
Hi Coiby,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linus/master]
[also build test WARNING on v6.9-rc5 next-20240426]
[cannot apply to tip/x86/core]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
On Wed, Apr 24, 2024 at 04:17:09PM -0500, Kalra, Ashish wrote:
> With SNP guest kexec and during nested guest kexec, observe the following
> efi memmap corruption :
Before we delve any deeper here, lemme make sure I understand this
correctly:
* You're in a SNP guest and you're kexec-ing into a
On 4/26/2024 10:22 AM, Borislav Petkov wrote:
On Fri, Apr 26, 2024 at 09:47:02AM -0500, Kalra, Ashish wrote:
I should have mentioned *chained* guest kexec above instead of nested guest
kexec.
What is a "chained guest kexec" now?
"Chained guest kexec" is when we are in a guest and kexec-ing
On Fri, Apr 26, 2024 at 09:32:52PM +, Justin Stitt wrote:
> Hi,
>
> On Wed, Apr 24, 2024 at 11:26:59AM -0700, Nathan Chancellor wrote:
> > On Wed, Apr 24, 2024 at 05:53:12PM +0200, Ard Biesheuvel wrote:
> > > arch/x86/purgatory/stack.S| 18 --
> >
> > This needs a
On Fri, Apr 26, 2024 at 2:53 PM Nathan Chancellor wrote:
>
> On Fri, Apr 26, 2024 at 09:32:52PM +, Justin Stitt wrote:
> > Hi,
> >
> > On Wed, Apr 24, 2024 at 11:26:59AM -0700, Nathan Chancellor wrote:
> > > On Wed, Apr 24, 2024 at 05:53:12PM +0200, Ard Biesheuvel wrote:
> > > >
Hi,
On Wed, Apr 24, 2024 at 11:26:59AM -0700, Nathan Chancellor wrote:
> On Wed, Apr 24, 2024 at 05:53:12PM +0200, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel
> >
> > The x86 purgatory, which does little more than verify a SHA-256 hash of
> > the loaded segments, currently uses three
23 matches
Mail list logo
