| Summary: | 13.0-RELEASE Installation media kernel panic under Qemu/KVM | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Yann Droneaud <yann> | ||||||||||||
| Component: | kern | Assignee: | freebsd-emulation (Nobody) <emulation> | ||||||||||||
| Status: | Closed Not A Bug | ||||||||||||||
| Severity: | Affects Only Me | CC: | cynix | ||||||||||||
| Priority: | --- | ||||||||||||||
| Version: | 13.0-RELEASE | ||||||||||||||
| Hardware: | amd64 | ||||||||||||||
| OS: | Any | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Yann Droneaud
2021-09-29 10:23:47 UTC
Created attachment 228243 [details]
kernel.log (verbose)
Created attachment 228244 [details]
libvirt guest description
I tried QEMU's Q53 and i440FX chipset configuration with same results. The issue can be worked around by setting a different CPU model from the host, host being an AMD Ryzen 9 5950x: specifing "EPYC" instead allows to boot to the installer. (In reply to Yann Droneaud from comment #4) Switching from "host" CPU model to EPYC CPU model as guest CPU, the kernel messages are modified this way: -CPU: AMD EPYC-Milan Processor (3393.63-MHz K8-class CPU) - Origin="AuthenticAMD" Id=0xa00f11 Family=0x19 Model=0x1 Stepping=1 +CPU: AMD EPYC Processor (3393.62-MHz K8-class CPU) + Origin="AuthenticAMD" Id=0x800f12 Family=0x17 Model=0x1 Stepping=2 Features=0x783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2> - Features2=0xfff83203<SSE3,PCLMULQDQ,SSSE3,FMA,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV> + Features2=0xfef83203<SSE3,PCLMULQDQ,SSSE3,FMA,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV> AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM> - AMD Features2=0xc003f7<LAHF,CMP,SVM,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,Topology,PCXC> - Structured Extended Features=0x219c07ab<FSGSBASE,TSCADJ,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA> - Structured Extended Features2=0x40060c<UMIP,PKU,VAES,VPCLMULQDQ,RDPID> - Structured Extended Features3=0xac000010<FSRM,IBPB,STIBP,ARCH_CAP,SSBD> - XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES> - IA32_ARCH_CAPS=0x69<RDCL_NO,SKIP_L1DFL_VME,MDS_NO> - AMD Extended Feature Extensions ID EBX=0x300d205<CLZERO,XSaveErPtr,WBNOINVD,IBPB,IBRS,STIBP,SSBD,VIRT_SSBD> + AMD Features2=0x4003f5<LAHF,SVM,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,Topology> + Structured Extended Features=0x209c01a9<FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA> + XSAVE Features=0x7<XSAVEOPT,XSAVEC,XINUSE> SVM: NP,NRIP,NAsids=16 Created attachment 228248 [details] kernel log as guest with Epyc as CPU model (In reply to Yann Droneaud from comment #5) Created attachment 228249 [details]
kernel log, booted on host computer (baremetal) instead of being virtualized
Bypassing libvirtd, but reusing some of the command line parameter it uses, I can reproduce the issue with qemu:
qemu-system-x86_64 -m 1024 \
-machine pc-q35-5.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off \
-cpu EPYC-Milan,x2apic=on,tsc-deadline=on,hypervisor=on,tsc-adjust=on,vaes=on,vpclmulqdq=on,spec-ctrl=on,stibp=on,arch-capabilities=on,ssbd=on,cmp-legacy=on,virt-ssbd=on,rdctl-no=on,skip-l1dfl-vmentry=on,mds-no=on,pschange-mc-no=on,pcid=off,svme-addr-chk=off \
-cdrom FreeBSD-13.0-RELEASE-amd64-disc1.iso
I will try to trim the options to the one that trigger the panic.
(In reply to Yann Droneaud from comment #8) Boot: qemu-system-x86_64 -m 1024 -machine pc-q35-5.2,accel=kvm -cpu EPYC -cdrom FreeBSD-13.0-RELEASE-amd64-disc1.iso qemu-system-x86_64 -m 1024 -machine pc-q35-5.2,accel=kvm -cpu EPYC-v1 -cdrom FreeBSD-13.0-RELEASE-amd64-disc1.iso qemu-system-x86_64 -m 1024 -machine pc-q35-5.2,accel=kvm -cpu EPYC-v2 -cdrom FreeBSD-13.0-RELEASE-amd64-disc1.iso qemu-system-x86_64 -m 1024 -machine pc-q35-5.2,accel=kvm -cpu EPYC-v3 -cdrom FreeBSD-13.0-RELEASE-amd64-disc1.iso qemu-system-x86_64 -m 1024 -machine pc-q35-5.2,accel=kvm -cpu EPYC-IBPB -cdrom FreeBSD-13.0-RELEASE-amd64-disc1.iso Panic: qemu-system-x86_64 -m 1024 -machine pc-q35-5.2,accel=kvm -cpu EPYC-Milan -cdrom FreeBSD-13.0-RELEASE-amd64-disc1.iso qemu-system-x86_64 -m 1024 -machine pc-q35-5.2,accel=kvm -cpu EPYC-Milan-v1 -cdrom FreeBSD-13.0-RELEASE-amd64-disc1.iso Problem also happen with 12.2 GENERIC kernel When testing against upstream Qemu, I've found v6.0.0 reproduces the problem, and v6.1.0 doesn't ! So maybe it's not a problem in FreeBSD implementation after all. Doing some bisecting, I've identified a commit in Qemu that seems to fix my issue: commit fea4500841024195ec701713e05b92ebf667f192 (HEAD) Author: David Edmondson <david.edmondson@oracle.com> Date: Mon Jul 5 11:46:31 2021 +0100 target/i386: Populate x86_ext_save_areas offsets using cpuid where possible Rather than relying on the X86XSaveArea structure definition, determine the offset of XSAVE state areas using CPUID leaf 0xd where possible (KVM and HVF). Signed-off-by: David Edmondson <david.edmondson@oracle.com> Message-Id: <20210705104632.2902400-8-david.edmondson@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> I can't tell anymore if there's a bug in FreeBSD kernel, so I'm closing the bug. (In reply to Yann Droneaud from comment #11) If you can't update QEMU or change CPU type on the host, another possible workaround is to add hw.use_xsave=0 to /boot/loader.conf. |