Bug 1715149

may related to bz1593190, but seems the stop code is different.

Could you please provide more info to see if it's same issue:
1.host cpu info via # lscpu;
2.qemu/kernel/virtio-win version
3.qemu command line while guest is booting up: #ps aux | grep qemu

$ lscpu 
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                64
On-line CPU(s) list:   0-63
Thread(s) per core:    2
Core(s) per socket:    8
Socket(s):             4
NUMA node(s):          8
Vendor ID:             AuthenticAMD
CPU family:            21
Model:                 2
Model name:            AMD Opteron(tm) Processor 6376

$ rpm -q virtio-win qemu-kvm-ev
virtio-win-0.1.141-1.noarch
qemu-kvm-ev-2.12.0-18.el7_6.5.1.x86_64 (from centos-qemu-ev repo)

3.10.0-957.12.2.el7.x86_64

(In reply to lejeczek from comment #3)
> $ lscpu 
> Architecture:          x86_64
> CPU op-mode(s):        32-bit, 64-bit
> Byte Order:            Little Endian
> CPU(s):                64
> On-line CPU(s) list:   0-63
> Thread(s) per core:    2
> Core(s) per socket:    8
> Socket(s):             4
> NUMA node(s):          8
> Vendor ID:             AuthenticAMD
> CPU family:            21
> Model:                 2
> Model name:            AMD Opteron(tm) Processor 6376
> 
> $ rpm -q virtio-win qemu-kvm-ev
> virtio-win-0.1.141-1.noarch

The driver is a little old, could you try with latest version?

> qemu-kvm-ev-2.12.0-18.el7_6.5.1.x86_64 (from centos-qemu-ev repo)
> 
> 3.10.0-957.12.2.el7.x86_64

And could you provide the qemu command line while guest is booting up?
#ps aux | grep qemu

Thanks

$ yum repoinfo virtio-win-stable
Repo-id      : virtio-win-stable
Repo-name    : virtio-win builds roughly matching what was shipped in latest RHEL
Repo-status  : enabled
Repo-revision: 1559167931
Repo-updated : Wed May 29 23:12:11 2019
Repo-pkgs    : 5
Repo-size    : 250 M
Repo-baseurl : http://fedorapeople.org/groups/virt/virtio-win/repo/stable/
Repo-expire  : 21,600 second(s) (last: Tue Jun 11 15:30:30 2019)
  Filter     : read-only:present
Repo-filename: /etc/yum.repos.d/virtio-win.repo

qemu      122019       1 97 1297977 195412 30 17:55 ?      00:00:32 /usr/libexec/qemu-kvm -name guest=win10-scratch,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-win10-scratch/master-key.aes -machine pc-i440fx-rhel7.2.0,accel=kvm,usb=off,dump-guest-core=off -cpu Opteron_G5,perfctr_core=on,skinit=on,perfctr_nb=on,mmxext=on,osxsave=on,vme=on,topoext=on,fxsr_opt=on,bmi1=on,ht=on,cr8legacy=on,ibs=on,wdt=on,extapic=on,osvw=on,nodeid_msr=on,tce=on,cmp_legacy=on,monitor=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 4,sockets=2,cores=2,threads=1 -uuid 2d5e45f7-5b1c-4d0a-9fbe-f9639316e7ea -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=42,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive file=gluster://127.0.0.1:24007/QEMU_VMs/scratch1.qcow2,file.debug=4,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/0-ALL.DATA/IT-RELATED/ISOs/Win10_1809Oct_v2_EnglishInternational_x64.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -drive file=/usr/share/virtio-win/virtio-win.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -netdev tap,fd=44,id=hostnet0,vhost=on,vhostfd=45 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:45:b8:3f,bus=pci.0,addr=0x3 -netdev tap,fd=46,id=hostnet1,vhost=on,vhostfd=47 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:66:35:84,bus=pci.0,addr=0x7 -netdev tap,fd=48,id=hostnet2,vhost=on,vhostfd=49 -device virtio-net-pci,netdev=hostnet2,id=net2,mac=52:54:00:30:a0:bc,bus=pci.0,addr=0x9 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=50,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -vnc 0.0.0.0:2,password -device qxl-vga,id=video0,ram_size=67108864,vram_size=16777216,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on

Thanks lejeczek.
Now I can reproduce this issue with following qemu cli, the root cause is "topoext=on" in cpu configuration, remove "topoext=on" from qemu cli, this issue disappear.

My qemu cli:
/usr/libexec/qemu-kvm \
-monitor stdio \
-machine pc-i440fx-rhel7.2.0,accel=kvm,usb=off,dump-guest-core=off \
-cpu Opteron_G5,perfctr_core=on,skinit=on,perfctr_nb=on,mmxext=on,osxsave=on,vme=on,topoext=on,fxsr_opt=on,bmi1=on,ht=on,cr8legacy=on,ibs=on,wdt=on,extapic=on,osvw=on,nodeid_msr=on,tce=on,cmp_legacy=on,monitor=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff \
-m 4096 -realtime mlock=off -smp 4,sockets=2,cores=2,threads=1 -no-user-config -nodefaults -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive file=win10-64.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/home/kvm_autotest_root/iso/ISO/Win10/en_windows_10_business_edition_version_1809_updated_sept_2018_x64_dvd_f0b7dc68.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -drive file=/home/kvm_autotest_root/iso/windows/virtio-win-prewhql-0.1-144.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -vnc 0.0.0.0:2 -device qxl-vga,id=video0,ram_size=67108864,vram_size=16777216,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on

Can you provide the XML for the 'win10-scratch' guest 

Trying to see what may be defined/set in order to create the command line option from comment 5:

...
-cpu Opteron_G5,perfctr_core=on,skinit=on,perfctr_nb=on,mmxext=on,osxsave=on,vme=on,topoext=on,fxsr_opt=on,bmi1=on,ht=on,cr8legacy=on,ibs=on,wdt=on,extapic=on,osvw=on,nodeid_msr=on,tce=on,cmp_legacy=on,monitor=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off 
...

where "topoext=on" is getting set.

Just to help or make it clear - I'm trying to figure out what/who set that bit for the Opteron_G5 cpu. All the libvirt code is doing is taking what flags are set in the XML and formatting the command line.

I'm assuming there's something like the following in the XML under/with some <cpu ... /cpu> definition:

   <feature policy='require' name='topoext'/>

What sets that and for what reason is what would need to be changed.  So understanding how the guest XML was created will also be quite useful

It might have been me done that manually, otherwise virt-install. But like I said, it works with 1709 and older, maybe with 1803 too.

This looks like the potential issue I had described in bug 1619798.  We need to confirm libvirt mode=host-model won't enable TOPOEXT automatically.

I see only two possibilities here: libvirt enabled the CPU feature automatically (meaning this is a duplicate of bug 1619798), or the feature was enabled manually (meaning it is not a bug).  I agree it should be moved to libvirt.

I was going to close this as duplicate of bz#1619798, but that BZ is for RHEL-AV-8 and this one is for RHEL-7.

As long as QEMU does not enable topoext for -cpu host (since
qemu-kvm-rhev-2.12.0-12.el7) libvirt would not enable the feature for
host-model CPUs.

So either the features was enabled manually or it was added by virt-install or
virt-manager. In 7.6 (and earlier) they used to copy the CPU definition from
host capabilities, which contains all features supported by the host CPU
without checking whether QEMU would enable them or not. Thus it would also
contain topoext. This is already tracked by bug 1525337 and it should be fixed
in RHEL 7.7.

I have no idea why it used to work with earlier revision of Win 10, but this
is not really important as the topoext feature should not be enabled.

In any case, there is an easy workaround... just remove the topoext feature
from the domain XML.

I'm closing this bug as a duplicate of the virt-manager bug I mentioned.

*** This bug has been marked as a duplicate of bug 1525337 ***