Bug 1788415
Summary: | packed=on: boot qemu with vhost-user and vIOMMU over OpenvSwitch, starting testpmd in guest will cause both qemu and ovs crash | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux Advanced Virtualization | Reporter: | Pei Zhang <pezhang> | |
Component: | qemu-kvm | Assignee: | lulu <lulu> | |
qemu-kvm sub component: | Networking | QA Contact: | Pei Zhang <pezhang> | |
Status: | CLOSED CURRENTRELEASE | Docs Contact: | ||
Severity: | high | |||
Priority: | high | CC: | aadam, amorenoz, chayang, eperezma, jinzhao, juzhang, virt-maint | |
Version: | 8.2 | |||
Target Milestone: | rc | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | If docs needed, set a value | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1793064 1793068 (view as bug list) | Environment: | ||
Last Closed: | 2020-09-21 06:58:48 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: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1793064, 1793068, 1812740, 1812741 |
Description
Pei Zhang
2020-01-07 06:27:13 UTC
Update OpenvSwith versions: openvswitch2.11-2.11.0-35.el8fdp.x86_64 If replace OpenvSwitch with dpdk's testpmd as vhost-user clients, qemu will work well. dpdk version: dpdk-19.11-1.el8.x86_64 Steps: 1. Replace Step 1 of Description with booting dpdk's testpmd, qemu will keep working well and testpmd can receive packets well. /usr/bin/testpmd \ -l 2,4,6,8,10,12,14,16,18 \ --socket-mem 1024,1024 \ -n 4 \ -d /usr/lib64/librte_pmd_vhost.so \ --vdev 'net_vhost0,iface=/tmp/vhostuser0.sock,queues=2,client=1,iommu-support=1' \ --vdev 'net_vhost1,iface=/tmp/vhostuser1.sock,queues=2,client=1,iommu-support=1' \ --iova-mode pa \ -- \ --portmask=f \ -i \ --rxd=512 --txd=512 \ --rxq=2 --txq=2 \ --nb-cores=8 \ --forward-mode=io testpmd> set portlist 0,2,1,3 testpmd> start testpmd> show port stats all ######################## NIC statistics for port 0 ######################## RX-packets: 88822640 RX-missed: 0 RX-bytes: 5329364952 RX-errors: 0 RX-nombuf: 0 TX-packets: 75692878 TX-errors: 0 TX-bytes: 4541579232 Throughput (since last show) Rx-pps: 147041 Rx-bps: 70580080 Tx-pps: 125307 Tx-bps: 60147664 ############################################################################ ######################## NIC statistics for port 1 ######################## RX-packets: 75693848 RX-missed: 0 RX-bytes: 4541637432 RX-errors: 0 RX-nombuf: 0 TX-packets: 88821732 TX-errors: 0 TX-bytes: 5329310472 Throughput (since last show) Rx-pps: 125307 Rx-bps: 60147664 Tx-pps: 147041 Tx-bps: 70580080 ############################################################################ There might be multiple issues going on here, so let's try to split them up: Looking at the code, qemu's implementation of vhost-user + multiqueue + iommu is likely to be utterly broken. It will create a slave channel per queue pair. When the second slave channel is created, the first one is closed by the vhost-user backend (which explains the "Failed to read from slave" errors). And when the first queue is started, SET_VRING_ADDR on queue pair 1 will generate an IOTBL_MISS on slave channel bound to queue pair 2. That is most likely the cause of qemu's segfault. I'll work upstream to fix that. If that's true: - It should be as reproducible with testpmd as it is with OvS. Pei, can you double check "queues=2" is present in qemu's command line for the testpmd case? - It should be as reproducible with or without "packed=on" Pei, can you please confirm this? Now, that does not explain OvS's crash. Can you please attach some logs to try to figure out what's going on there? Thanks Hi Adrián, I've been trying to reproduce this issue many times (As I cannot reproduce with libvirt at first, but 100% reproduced). Finally I found the way to reproduce, no matter with qemu or libvirt. Here is the update: 1. vIOMMU + packed=on + memory host-nodes=1 are 3 key points to reproduce the issue 100%. Without one of them, this issue can not be reproduced. -chardev socket,id=charnet1,path=/tmp/vhostuser0.sock,server \ -netdev vhost-user,chardev=charnet1,queues=2,id=hostnet1 \ -device virtio-net-pci,mq=on,vectors=6,rx_queue_size=1024,netdev=hostnet1,id=net1,mac=88:66:da:5f:dd:02,bus=pci.6,addr=0x0,iommu_platform=on,ats=on,packed=on \ -chardev socket,id=charnet2,path=/tmp/vhostuser1.sock,server \ -netdev vhost-user,chardev=charnet2,queues=2,id=hostnet2 \ -device virtio-net-pci,mq=on,vectors=6,rx_queue_size=1024,netdev=hostnet2,id=net2,mac=88:66:da:5f:dd:03,bus=pci.7,addr=0x0,iommu_platform=on,ats=on,packed=on \ -object memory-backend-file,id=mem,size=8G,mem-path=/dev/hugepages,share=on,host-nodes=1,policy=bind \ -numa node,memdev=mem -mem-prealloc \ 2. When I reported this bz, I didn't explicitly set memory host-nodes=1, but in my setup it's default using memory host-nodes=1. (When we set memory host-nodes=0, it works very well) Sorry for late response. I just wanted to provide some certain testing results to avoid possible confusion and this took a bit long time. (In reply to Pei Zhang from comment #8) > Hi Adrián, > > I've been trying to reproduce this issue many times (As I cannot reproduce > with libvirt at first, but 100% reproduced). fix typo: but 100% reproduced with qemu. (In reply to Adrián Moreno from comment #7) > There might be multiple issues going on here, so let's try to split them up: > > Looking at the code, qemu's implementation of vhost-user + multiqueue + > iommu is likely to be utterly broken. It will create a slave channel per > queue pair. When the second slave channel is created, the first one is > closed by the vhost-user backend (which explains the "Failed to read from > slave" errors). And when the first queue is started, SET_VRING_ADDR on queue > pair 1 will generate an IOTBL_MISS on slave channel bound to queue pair 2. > That is most likely the cause of qemu's segfault. I'll work upstream to fix > that. > Hi Adrian, I've filed a bz to track the multiqueue issue with dpdk19.11. This one is not related to packed=on. I've already cc you. Bug 1793327 - "qemu-kvm: Failed to read from slave." shows when boot qemu vhost-user 2 queues over dpdk 19.11 Best regards, Pei QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks Update: With ovs patch fix of Bug 1812620, both ovs and qemu crash issues are gone. Both ovs and qemu keep working well and the throughput result looks good. Testcase: nfv_acceptance_nonrt_server_2Q_1G_iommu_packed Packets_loss Frame_Size Run_No Throughput Avg_Throughput 0 64 0 20.950139 20.950139 Versions: 4.18.0-187.el8.x86_64 qemu-kvm-4.2.0-13.module+el8.2.0+5898+fb4bceae.x86_64 tuned-2.13.0-5.el8.noarch python3-libvirt-6.0.0-1.module+el8.2.0+5453+31b2b136.x86_64 openvswitch2.13-2.13.0-6.el8fdp.x86_64 dpdk-19.11-4.el8.x86_64 More info: The ovs patch can fix both qemu and ovs crash issue. With latest fdp ovs2.11, ovs2.12, ovs2.13, both qemu and ovs work well. Below is more testing versions: ovs2.11: openvswitch2.11-2.11.0-35.el8fdp.x86_64, qemu-kvm-4.2.0-13.module+el8.2.0+5898+fb4bceae.x86_64: both qemu and ovs crash. openvswitch2.11-2.11.0-50.el8fdp.x86_64, qemu-kvm-4.2.0-13.module+el8.2.0+5898+fb4bceae.x86_64: both qemu and ovs work well. ovs2.12: openvswitch2.12-2.12.0-12.el8fdp.x86_64, qemu-kvm-4.2.0-13.module+el8.2.0+5898+fb4bceae.x86_64: both qemu and ovs crash. openvswitch2.12-2.12.0-23.el8fdp.x86_64, qemu-kvm-4.2.0-13.module+el8.2.0+5898+fb4bceae.x86_64: both qemu and ovs work well. ovs2.13: openvswitch2.13-2.13.0-6.el8fdp.x86_64, qemu-kvm-4.2.0-13.module+el8.2.0+5898+fb4bceae.x86_64: both qemu and ovs work well. Hi Cindy, From QE function and performance testing perspective, the qemu crash issue has gone with ovs fix. This bug can not be reproduced any more. However I'm not sure if there were some defects in qemu code and might be covered by the ovs fix. After discussed with pei, We plan to move this to AV8.4 Hi pei, I have checked the log and the fix, I thinks the fix in dpdk have already fix this crash, We don't need fix it in qemu. Maybe we can close this bug? (In reply to lulu from comment #23) > Hi pei, I have checked the log and the fix, I thinks the fix in dpdk have > already fix this crash, We don't need fix it in qemu. Maybe we can close > this bug? Hi Cindy, Thanks for the explain. I agree we can close it. Best regards, Pei |