Bug 1684063

Summary:	Network doesn't work well in win2019 guest when booting qemu with 4 queues and 1 vector
Product:	Red Hat Enterprise Linux Advanced Virtualization	Reporter:	Lei Yang <leiyang>
Component:	qemu-kvm	Assignee:	Virtualization Maintenance <virt-maint>
qemu-kvm sub component:	General	QA Contact:	Virtualization Bugs <virt-bugs>
Status:	CLOSED DUPLICATE	Docs Contact:
Severity:	unspecified
Priority:	unspecified	CC:	chayang, jen, jinzhao, juzhang, leiyang, pezhang, rbalakri, virt-maint, wyu, ybendito
Version:	8.1
Target Milestone:	rc
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-03-01 09:12:47 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Lei Yang 2019-02-28 10:42:38 UTC

Description of problem:
Test win2019 guest booting with different vectors. Guest network works well with vectors 0/2/3/4/5, however network is down when vectors=1.

Version-Release number of selected component (if applicable):
kernel-4.18.0-67.el8.x86_64
virtio-win-1.9.7-3.el8.noarch
qemu-kvm-3.1.0-17.module+el8+2831+8d13a174.x86_64

How reproducible:
10/10

Steps to Reproduce:
1.Boot win2019 guest with queues=4 and vectors=1. qemu prompts errors.

/usr/libexec/qemu-kvm -name Win2019 \
-M q35,kernel-irqchip=split -m 4g \
-cpu EPYC,hv_stimer,hv_synic,hv_time,hv_relaxed,hv_vpindex,hv_spinlocks=0xfff,hv_vapic,hv_reset,hv_crash \
-device intel-iommu,intremap=true,caching-mode=true \
-smp 4,sockets=1,cores=4,threads=1 \
-device pcie-root-port,id=root.1,chassis=1 \
-device pcie-root-port,id=root.2,chassis=2 \
-blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/home/win2019.qcow2,node-name=my_file \
-blockdev driver=qcow2,node-name=my,file=my_file \
-device virtio-blk-pci,drive=my,id=virtio-blk0,bus=root.1 \
-drive id=drive_cd1,if=none,snapshot=off,aio=native,cache=none,media=cdrom,file=/home/en_windows_server_2019_x64_dvd_4cb967d8.iso \
-device ide-cd,id=cd1,drive=drive_cd1,bus=ide.0,unit=0 \
-drive id=drive_winutils,if=none,snapshot=off,aio=native,cache=none,media=cdrom,file=/usr/share/virtio-win/virtio-win-1.9.7.iso \
-device ide-cd,id=winutils,drive=drive_winutils,bus=ide.1,unit=0 \
-vnc :3 \
-vga qxl \
-monitor stdio \
-usb -device usb-tablet \
-boot menu=on \
-netdev tap,id=hostnet1,vhost=on,queues=4 \
-device virtio-net-pci,indirect_desc=off,netdev=hostnet1,id=net1,mac=18:66:da:5f:d1:02,bus=root.2,vectors=1,mq=on \

(qemu) qemu-kvm: unable to start vhost net: 14: falling back on userspace virtio
qemu-kvm: warning: guest updated active QH
qemu-kvm: warning: guest updated active QH
qemu-kvm: warning: guest updated active QH
qemu-kvm: warning: guest updated active QH
qemu-kvm: warning: guest updated active QH

2.Check guest Network status-->Not connected


Actual results:
Network is down.

Expected results:
Network is up.


Additional info:
1. It's possibly same issue with issue in rhel7.6:
Bug 1608226 - [virtual-network][mq] prompt warning "qemu-kvm: unable to start vhost net: 14: falling back on userspace virtio" when boot with win8+ guests with multi-queue

Comment 1 Pei Zhang 2019-03-01 09:12:47 UTC

This is a virtio-win bug. And it's duplicate with Bug 1666940.

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

Comment 2 ybendito 2019-03-01 10:12:33 UTC

It does not seem this bug is duplicate of Bug 1666940 (1666940 is related to virtio-win-prewhql 162/163)
This BZ is open for virtio-win 160 (virtio-win-1.9.7-3.el8), with netkvm build 160 the network shall function with single vector (just with not optimal performance).
"falling back on userspace virtio" - does not indicate any fatal problem, just a fallback to qemu networking instead of vhost.
Please verify the problem happens with netkvm build 160 (netkvm.inf and netkvm.sys has version .16400)

Comment 3 ybendito 2019-03-01 10:17:34 UTC

(netkvm.inf and netkvm.sys has version .16000)

Comment 4 Yu Wang 2019-03-05 08:55:24 UTC

(In reply to ybendito from comment #3)
> (netkvm.inf and netkvm.sys has version .16000)

But for ws2019, we use build 162 in virtio-win-1.9.7-3.el8.noarch, other guests are build 160.

Comment 5 ybendito 2019-03-05 09:02:50 UTC

(In reply to Yu Wang from comment #4)
> (In reply to ybendito from comment #3)
> > (netkvm.inf and netkvm.sys has version .16000)
> 
> But for ws2019, we use build 162 in virtio-win-1.9.7-3.el8.noarch, other
> guests are build 160.

OK, sorry, I've missed this point. So, yes, the build 162 is buggy. Latest builds (165+) shall fix the problem.