On Sat, Dec 30, 2017 at 09:23:03PM -0800, Mike Larkin wrote: > 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 >
Following up on old email threads; see the recent message by sf@ regarding disabling certain KVM features that may help here. -ml
