On Tue, Jan 02, 2018 at 11:30:47AM -0500, Brian Rak wrote: > > > On 12/30/2017 5:13 PM, Mike Larkin wrote: > > On Wed, Dec 27, 2017 at 01:10:13PM -0500, Brian Rak wrote: > > > I have a server with an Intel Platinum CPU: > > > https://ark.intel.com/products/120505/Intel-Xeon-Platinum-8176M-Processor-38_5M-Cache-2_10-GHz > > > > > > It's running Fedora 27 Server, kernel version 4.14.8-300.fc27.x86_64, > > > qemu-system-x86-core-2.10.1-2.fc27.x86_64 > > > > > > I'm starting qemu like this: > > > > > > /usr/bin/qemu-system-x86_64 -machine accel=kvm -name > > > guest=test,debug-threads=on -S -object > > > secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-6-test/master-key.aes > > > -machine pc-i440fx-2.10,accel=kvm,usb=off,dump-guest-core=off -cpu > > > Skylake-Client,hypervisor=on -m 32768 -realtime mlock=off -smp > > > 16,sockets=2,cores=8,threads=1 -uuid 6427e485-5aee-4fb6-b5e5-a80c1dc0f4af > > > -no-user-config -nodefaults -chardev > > > socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-6-test/monitor.sock,server,nowait > > > -mon chardev=charmonitor,id=monitor,mode=control -rtc > > > base=utc,driftfix=slew > > > -global kvm-pit.lost_tick_policy=delay -no-shutdown -boot strict=on > > > -device > > > piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive > > > file=/var/tmp/cd62.iso,format=raw,if=none,id=drive-ide0-1-0,readonly=on > > > -device > > > ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 > > > -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=32 -device > > > virtio-net-pci,netdev=hostnet0,id=net0,mac=56:00:00:27:d6:3f,bus=pci.0,addr=0x3,rombar=0,bootindex=3 > > > -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc > > > 127.0.0.1:4788,websocket=40688 -device > > > cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device > > > virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -object > > > rng-random,id=objrng0,filename=/dev/random -device > > > virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x6 -msg timestamp=on > > Could you try a simpler config? There's a lot in there that's not needed for > > OpenBSD, and I'm wondering if there is some option you've chosen that's > > causing problems. > > > > For what it's worth, there have been a number of reports of OpenBSD guests > > recently failing when run on KVM (mainly clock related issues but other > > things as well). You are using a very new CPU on a very new host OS, I'm not > > surprised some things are behaving a bit strangely. > > > > -ml > The simplest command line I can come up with is: > > /usr/bin/qemu-system-x86_64 -machine accel=kvm -name guest=test -machine > pc-i440fx-2.10 -cpu Skylake-Client -m 32768 -drive > file=/var/tmp/cd62.iso,format=raw,if=none,id=drive-ide0-1-0,readonly=on > -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 > -device cirrus-vga,id=video0,bus=pci.0,addr=0x3 -vnc 127.0.0.1:4788 > > I still see the same hang. Even using more ancient virtual CPUs (-cpu > pentium3) doesn't seem to help. > > Switching to '-machine pc-q35-2.10' doesn't appear to help either. > > If I disable KVM, the instance appears to boot normally. However, I'm not > sure if this points to a KVM issue or if it's just masking a timing issue > (because it runs so much slower emulated) > > In this case, we went with Fedora 27 to rule out a problem that would be > fixed by upgrading some part of the host OS. This isn't an OS we normally > use, and we've seen issues with older versions of qemu. >
The only thing I can say is that recently I've been noticing an uptick in the quantity of KVM related issues on OpenBSD. Whether this is due to some recent changes in KVM, or maybe due to more people running OpenBSD on KVM (and thus increasing the number of reports), I'm not sure. But kettenis@ did note a few days ago in a reply to a different KVM related issue that it seems their local APIC emulation code isn't behaving exactly as we expect. But that code hasn't changed in OpenBSD since, well, forever, so it's likely a KVM issue there. Whether this is your issue or not I don't know. You might bring this up on the KVM mailing lists and see if someone can shed light on it. If you search the tech@/misc@ archives for proxmox related threads, there was a KVM option reported a week or so back that seemed to fix the issue kettenis@ was commenting on; perhaps this can help you. -ml
