On Sun, Nov 15, 2020 at 06:20:52PM +0000, Gabriel Garcia wrote: > Hi, > > I would like to run OpenBSD as stated on the subject - I have been able, > however, to run it successfully with "-cpu Opteron_G2-v1", but I would > rather use "-cpu host" instead. Also note that on an Intel host, OpenBSD > appears to work successfully on the same Linux base. > > qemu invocation that yields a trap: > qemu-system-x86_64 -enable-kvm -machine q35 -cpu > host,-nodeid-msr,-vmx-msr-bitmap,-popcnt,-tsc-deadline,-mmxext,-fxsr-opt,-pdpe1gb,-rdtscp,-3dnow,-3dnowext,-cmp-legacy,-svm,-cr8legacy,-abm,-sse4a,-misalignsse,-3dnowprefetch,-osvw,-amd-no-ssb > \ > > -drive file=/path/to/raw.img,format=raw,if=virtio \ > > -m 512M \ > > -display curses > > (note that `-cpu host` without deactivating any flag also yields a trap) > > dmesg output: > ddb> dmesg > > OpenBSD 6.8 (GENERIC) #1: Tue Nov 3 09:04:47 MST 2020 > > > r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > real mem = 519954432 (495MB) > > avail mem = 489299968 (466MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5aa0 (9 entries) > > bios0: vendor SeaBIOS version > "?-20190711_202441-buildvm-armv7-10.arm.fedorapro > > ject.org-2.fc31" date 04/01/2014 > > bios0: QEMU Standard PC (Q35 + ICH9, 2009) > > acpi0 at bios0: ACPI 3.0 > > acpi0: sleep states S3 S4 S5 > > acpi0: tables DSDT FACP APIC HPET MCFG WAET > > acpi0: wakeup devices > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: AMD Turion(tm) II Neo N40L Dual-Core Processor, 1497.89 MHz, 10-06-03 > > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH, > MMX,FXSR,SSE,SSE2,SSE3,CX16,x2APIC,POPCNT,DEADLINE,HV,NXE,MMXX,FFXSR,PAGE1GB, > RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW, > > SSBDNR > > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB > 64b/line 1 > > 6-way L2 cache, 16MB 64b/line 16-way L3 cache > > cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > > cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > > kernel: protection fault trap, code=0 > > Stopped at amd64_errata_setmsr+0x4e: wrmsr > > > Contents of CPU registers: > ddb> show registers > > rdi 0x9c5a203a > > rsi 0xffffffff820ff920 errata+0xe0 > > rbp 0xffffffff824c5740 end+0x2c5740 > > rbx 0x18 > > rdx 0 > > rcx 0xc0011029 > > rax 0x3 > > r8 0xffffffff824c55a8 end+0x2c55a8 > > r9 0 > > r10 0xbdf7dabff85d847b > > r11 0x51e076fef1dcfa7b > > r12 0 > > r13 0 > > r14 0xffffffff820ff940 acpihid_ca > > r15 0xffffffff820ff920 errata+0xe0 > > rip 0xffffffff81bc6ede amd64_errata_setmsr+0x4e > > cs 0x8 > > rflags 0x10256 __ALIGN_SIZE+0xf256 > > rsp 0xffffffff824c5730 end+0x2c5730 > > ss 0x10 > > amd64_errata_setmsr+0x4e: wrmsr > > > > Working system dmesg (only change from invocation above is "-cpu > Opteron_G2-v1"): > OpenBSD 6.8 (GENERIC) #1: Tue Nov 3 09:04:47 MST 2020 > > > r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > real mem = 519950336 (495MB) > > avail mem = 489304064 (466MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5aa0 (9 entries) > > bios0: vendor SeaBIOS version > "?-20190711_202441-buildvm-armv7-10.arm.fedoraproject.org-2.fc31" date > 04/01/2014 > > bios0: QEMU Standard PC (Q35 + ICH9, 2009) > > acpi0 at bios0: ACPI 3.0 > > acpi0: sleep states S3 S4 S5 > > acpi0: tables DSDT FACP APIC HPET MCFG WAET > > acpi0: wakeup devices > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: AMD Opteron 22xx (Gen 2 Class Opteron), 1497.89 MHz, 0f-06-01 > > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, > CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF > > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB > 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 cache > > cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > > cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > > cpu0: smt 0, core 0, package 0 > > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > > cpu0: apic clock running at 999MHz > > ioapic0 at mainbus0: apid 0 pa 0xfec00000, version 11, 24 pins > > acpihpet0 at acpi0: 100000000 Hz > > acpimcfg0 at acpi0 > > acpimcfg0: addr 0xb0000000, bus 0-255 > > acpiprt0 at acpi0: bus 0 (PCI0) > > "ACPI0006" at acpi0 not configured > > acpipci0 at acpi0 PCI0: 0x00000000 0x00000011 0x00000001 > > acpicmos0 at acpi0 > > "PNP0A06" at acpi0 not configured > > "PNP0A06" at acpi0 not configured > > "QEMU0002" at acpi0 not configured > > "ACPI0010" at acpi0 not configured > > acpicpu0 at acpi0: C1(@1 halt!) > > pvbus0 at mainbus0: KVM > > pvclock0 at pvbus0 > > pci0 at mainbus0 bus 0 > > pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00 > > vga1 at pci0 dev 1 function 0 "Bochs VGA" rev 0x02 > > wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) > > wsdisplay0: screen 1-5 added (80x25, vt100 emulation) > > virtio0 at pci0 dev 2 function 0 "Qumranet Virtio Network" rev 0x00 > > vio0 at virtio0: address 9a:00:00:00:00:00 > > virtio0: msix shared > > xhci0 at pci0 dev 3 function 0 vendor "Red Hat", unknown product 0x000d rev > 0x01: apic 0 int 23, xHCI 0.0 > > usb0 at xhci0: USB revision 3.0 > > uhub0 at usb0 configuration 1 interface 0 "Red Hat xHCI root hub" rev > 3.00/1.00 addr 1 > > virtio1 at pci0 dev 4 function 0 "Qumranet Virtio Storage" rev 0x00 > > vioblk0 at virtio1 > > scsibus1 at vioblk0: 1 targets > > sd0 at scsibus1 targ 0 lun 0: <VirtIO, Block Device, > > > sd0: 51200MB, 512 bytes/sector, 104857600 sectors > > virtio1: msix shared > > pcib0 at pci0 dev 31 function 0 "Intel 82801IB LPC" rev 0x02 > > ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x02: msi, AHCI 1.0 > > ahci0: port 2: 1.5Gb/s > > scsibus2 at ahci0: 32 targets > > cd0 at scsibus2 targ 2 lun 0: <QEMU, QEMU DVD-ROM, 2.5+> removable > > ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x02: apic 0 int > 16 > > iic0 at ichiic0 > > isa0 at pcib0 > > isadma0 at isa0 > > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo > > pckbc0 at isa0 port 0x60/5 irq 1 irq 12 > > pckbd0 at pckbc0 (kbd slot) > > wskbd0 at pckbd0: console keyboard, using wsdisplay0 > > pms0 at pckbc0 (aux slot) > > wsmouse0 at pms0 mux 0 > > pcppi0 at isa0 port 0x61 > > spkr0 at pcppi0 > > lpt0 at isa0 port 0x378/4 irq 7 > > axe0 at uhub0 port 5 configuration 1 interface 0 "ASIX Electronics AX88772" > rev 2.00/0.01 addr 2 > > axe0: AX88772, address 00:50:b6:0b:cf:f0 > > ukphy0 at axe0 phy 16: Generic IEEE 802.3u media interface, rev. 1: OUI > 0x000ec6, model 0x0006 > > vscsi0 at root > > scsibus3 at vscsi0: 256 targets > > softraid0 at root > > scsibus4 at softraid0: 256 targets > > root on sd0a (50fd7af99e5255c1.a) swap on sd0b dump on sd0b > > > I have been trying to disable features on qemu invocation, changing the > "-machine" parameter and unloading the Linux msr module, without too much > success. Folks in #qemu suggested the workaround I'm using and advised that > the problem may be a CPU feature that I ought to disable, somehow. > > I know about https://www.openbsd.org/lyrics.html#62 (No QEMU, only DDB) :-) > However, if anybody has bumped into this and can successfully run OpenBSD as > a guest on this type of hardware, I would be grateful if they could throw me > a few ideas for me to try out. > > Thanks! > > > Gabriel
Sorry, this is either a QEMU/KVM bug or user config error. The kernel code was written to run on actual hardware and we avoid additional complexity caused by buggy VMs. Absent from this report is what version of KVM/QEMU is being used, but there are some indications it may be rather ancient.. You haven't said what happens when you don't try to explictly override the '-cpu' argument, but really it should be very clear to you that KVM is NOT matching the host CPU behaviour, despite what it claims. You can easily verify that by booting OpenBSD on the bare metal. -Bryan.
