Performing verification for Bionic. I installed the current 4.15.0-162-generic kernel from -updates to a host in segmaas, and brought up my Bionic VM I installed for the reproducer. The Bionic VM has linux-crashdump configured, with nr_cpus configured to 8:
ubuntu@bionic-vm:~$ kdump-config show DUMP_MODE: kdump USE_KDUMP: 1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR: /var/crash crashkernel addr: 0x /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-4.15.0-159-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-159-generic current state: ready to kdump kexec command: /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-159-generic root=UUID=5c23b432-4d00-4a01-8ecd-964803c8e10a ro console=tty1 console=ttyS0 reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=8 irqpoll nousb ata_piix.prefer_ms_hyperv=0 ignore_loglevel nmi_debug=state,regs apic_extnmi=none" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz I then triggered the crashdump in the VM: $ sudo -s # echo c > /proc/sysrq-trigger On the host, we look at the tail of: $ sudo tail -f /var/log/libvirt/qemu/bionic-vm.log ... KVM internal error. Suberror: 1 emulation failure EAX=0000de8f EBX=00000000 ECX=0000008f EDX=00000600 ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000f90c EIP=0000cdb1 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 0000ffff 00009300 CS =f000 000f0000 0000ffff 00009b00 SS =de00 000de000 0000ffff 00009300 DS =de00 000de000 0000ffff 00009300 FS =0000 00000000 0000ffff 00009300 GS =0000 00000000 0000ffff 00009300 LDT=0000 00000000 0000ffff 00008200 TR =0000 00000000 0000ffff 00008b00 GDT= 00000000 0000ffff IDT= 00000000 0000ffff CR0=60000010 CR2=00000000 CR3=32b2a000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 Code=66 83 c4 28 66 5b 66 c3 66 56 66 53 66 52 b1 8f 88 c8 e6 70 <e4> 71 66 0f b6 f0 66 89 f2 67 88 54 24 03 88 c8 e6 70 66 31 db 88 d8 e6 71 66 56 66 68 1a $ virsh list Id Name State ---------------------------------------------------- 1 bionic-vm paused Okay, we can reproduce the issue. I then enabled -proposed, and installed the 4.15.0-163-generic kernel: $ uname -rv 4.15.0-163-generic #171-Ubuntu SMP Fri Nov 5 11:55:11 UTC 2021 I started the same VM, verified it has a crashkernel with nr_cpus=8: $ kdump-config show DUMP_MODE: kdump USE_KDUMP: 1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR: /var/crash crashkernel addr: 0x /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-4.15.0-159-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-159-generic current state: ready to kdump kexec command: /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-159-generic root=UUID=5c23b432-4d00-4a01-8ecd-964803c8e10a ro console=tty1 console=ttyS0 reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=8 irqpoll nousb ata_piix.prefer_ms_hyperv=0 ignore_loglevel nmi_debug=state,regs apic_extnmi=none" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz I then triggered the crashdump: $ sudo -s # echo c > /proc/sysrq-trigger On the host: $ sudo tail -f /var/log/libvirt/qemu/bionic-vm.log ... 2021-11-11T02:41:45.970264Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] 2021-11-11T02:41:45.971185Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] $ virsh list Id Name State ---------------------------------------------------- 1 bionic-vm running Checking the VM, the crashdump completed successfully and restarted correctly. $ virsh console bionic-vm ... Copying data : [100.0 %] \ eta: 0s [ 12.034361] kdump-tools[874]: The dumpfile is saved to /var/crash/202111110246/dump-incomplete. [ 12.036787] kdump-tools[874]: makedumpfile Completed. [ 12.038752] kdump-tools[874]: * kdump-tools: saved vmcore in /var/crash/202111110246 [ 12.058489] kdump-tools[874]: * running makedumpfile --dump-dmesg /proc/vmcore /var/crash/202111110246/dmesg.202111110246 [ 12.069700] kdump-tools[874]: The dmesg log is saved to /var/crash/202111110246/dmesg.202111110246. [ 12.072574] kdump-tools[874]: makedumpfile Completed. [ 12.074245] kdump-tools[874]: * kdump-tools: saved dmesg content in /var/crash/202111110246 [ 12.159319] kdump-tools[874]: Thu, 11 Nov 2021 02:46:54 +0000 ... I then did this a further 4 times, each time the crashdump completed succesfully. I then destroyed and started the VM fresh, and kept crashdumping. It worked every time. The 4.15.0-163-generic kernel in -proposed fixes the issue. Happy to mark as verified. ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1948862 Title: KVM emulation failure when booting into VM crash kernel with multiple CPUs Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux source package in Focal: Fix Committed Bug description: [Impact] When kexec'ing into a crash kernel with ncpus > 1, VMs can raise a KVM emulation failure. This will cause the VM to go into the "paused" state, and prevents it from being restored without a full VM restart. This happens only when there are multiple enabled CPUs in the crash kernel command-line, regardless of whether `nr_cpus` or `maxcpus` is being used. Due to the vCPU MMU state not being cleaned up correctly, the secondary CPUs try to access virtual addresses with a faulty MMU context that will result in the emulation failure. This shows up with a similar spew as below: $ sudo tail -n20 /var/log/libvirt/qemu/focal-vm.log KVM internal error. Suberror: 1 emulation failure EAX=0000de8f EBX=00000000 ECX=0000008f EDX=00000600 ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000f90c EIP=0000cdb1 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 0000ffff 00009300 CS =f000 000f0000 0000ffff 00009b00 SS =de00 000de000 0000ffff 00009300 DS =de00 000de000 0000ffff 00009300 FS =0000 00000000 0000ffff 00009300 GS =0000 00000000 0000ffff 00009300 LDT=0000 00000000 0000ffff 00008200 TR =0000 00000000 0000ffff 00008b00 GDT= 00000000 0000ffff IDT= 00000000 0000ffff CR0=60000010 CR2=00000000 CR3=290b8001 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 Code=66 83 c4 28 66 5b 66 c3 66 56 66 53 66 52 b1 8f 88 c8 e6 70 <e4> 71 66 0f b6 f0 66 89 f2 67 88 54 24 03 88 c8 e6 70 66 31 db 88 d8 e6 71 66 56 66 68 1a [Test Plan] 1. Boot an Ubuntu guest VM with e.g. multipass: $ multipass launch daily:focal -c8 -m16g -n focal-vm 2. Configure guest crash kernel command-line with `nr_cpus=8`: ubuntu@focal-vm:~$ grep CMDLINE_APPEND /etc/default/kdump-tools # KDUMP_CMDLINE_APPEND - Additional arguments to append to the command line KDUMP_CMDLINE_APPEND="reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=8 irqpoll nousb ata_piix.prefer_ms_hyperv=0" 3. Crash guest VM and watch for the KVM emulation failure: ubuntu@focal-vm:~$ echo c | sudo tee /proc/sysrq-trigger [Where problems could occur] As we're resetting MMU context on vCPUs, potential regressions would show up in workloads relying on KVM guests. We should properly test the scenario mentioned in the bug to make sure secondary CPUs are being cleaned up properly, and that no other regressions have been introduced when rebooting or kexec'ing into different kernels. Since we're adding an MMU reset at kvm_vcpu_reset(), the overall regression potential should be fairly low and contained to starting/resetting vCPUs (i.e. VM start and reboot). [Other info] This has been fixed by upstream commit: 0aa1837533e5 KVM: x86: Properly reset MMU context at vCPU RESET/INIT The commit above has been picked up by stable trees up until 5.11, so it's only needed in Bionic and Focal (4.15 and 5.4 kernels). There are also two follow up commits, which revert the vendor-specific resets: 5d2d7e41e3b8 KVM: SVM: Drop explicit MMU reset at RESET/INIT 61152cd907d5 KVM: VMX: Remove explicit MMU reset in enter_rmode() These follow ups have not been picked up in stable trees due to the risk of regressions. According to the original fix, they have been introduced primarily to aid bisection in case there are workflows relying on the vendor resets. As these are not required for the fix and don't conflict with the backport, we should leave them out to prevent potential regressions in the older kernels. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1948862/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
