Commits on Jan 18, 2023

1. [warm-reboot] Use kexec_file_load instead of kexec_load when available …

   On some dev VMs, warm reboot on a VS image fails. Specifically, after
   kexec is called and the new kernel starts, the new kernel tries to load
   the initramfs, but fails to do so for whatever reason. There may be
   messages about gzip decompression failing and that it's corrupted.
   
   After some experimentation, it was found that when first loading the new
   kernel and initramfs into memory, using the `kexec_file_load` syscall
   (`-s` flag in kexec) worked fine, whereas using the default `kexec_load`
   syscall resulted in a failure. It's unknown why `kexec_file_load` worked
   fine when `kexec_load` didn't; there shouldn't be any difference for
   non-secure boot kernels, as far as I can tell. What was seen, however,
   was that when taking a KVM dump in the failure case, the memory that
   stored the initramfs had differences compared to what was on disk. It's
   unknown what caused these differences.
   
   As a workaround (and as a bit of a feature enhancement), use the `-a`
   flag with kexec, which tells it to use `kexec_file_load` if available,
   and `kexec_load` if it's not available or otherwise fails. armhf doesn't
   support `kexec_file_load`, whereas arm64 gained support for
   `kexec_file_load` in the 5.19 kernel (we're currently on 5.10). `amd64`
   has supported `kexec_file_load` since 3.17. This also makes it possible
   to do kexec on secure boot systems, where the kernel image must be
   loaded via `kexec_file_load`.
   
   Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>

   

   saiarcot895 committed Jan 18, 2023
   Configuration menu

   • View commit details
   • Copy full SHA for 29a0d20
   • Browse repository at this point

   Copy the full SHA

   29a0d20 View commit details

   Browse the repository at this point in the history