Bug 1609643
| Summary: | Running/destroying testpmd in guest which enabling vIOMMU can cause host ovs-vswitchd[10869]: segfault | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Pei Zhang <pezhang> | ||||
| Component: | openvswitch | Assignee: | Maxime Coquelin <maxime.coquelin> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Pei Zhang <pezhang> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.6 | CC: | ailan, atelang, atragler, chayang, ctrautma, juzhang, kfida, lmanasko, michen, ovs-qe, qding, siliu, tredaelli | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | openvswitch-2.9.0-59.el7fdn | Doc Type: | No Doc Update | ||||
| Doc Text: |
undefined
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2018-11-05 14:59:03 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: | |||||||
| Attachments: |
|
||||||
Additional info: 1. Without enabling vIOMMU support, ovs works well. So this issue only happens when enabling vIOMMU. 2. This should not be a regression bug. As testing with below old versions, still hit same issue. openvswitch-2.9.0-15.el7fdp.x86_64 fail openvswitch-2.9.0-1.el7fdp.x86_64 fail Hi Pei, I tried to reproduce with using testpmd on host instead of OVS, but it does not crash, even when generating traffic from host. Could you generate a coredump of OVS? I think it would help to understand what is happening. Thanks I tried again with OVS but still does not reproduce: openvswitch-2.9.0-47.el7fdp.2.x86_64 qemu-kvm-rhev-2.12.0-8.el7.x86_64 kernel-3.10.0-927.el7.x86_64 dpdk-17.11-11.el7.x86_64 Do you have traffic generator started to reproduce? (In reply to Maxime Coquelin from comment #3) > Hi Pei, > > I tried to reproduce with using testpmd on host instead of OVS, > but it does not crash, even when generating traffic from host. > > Could you generate a coredump of OVS? I think it would help to > understand what is happening. > > Thanks Hi Maxime, Here is the coredump info of OVS: http://pastebin.test.redhat.com/626299 (In reply to Maxime Coquelin from comment #4) > I tried again with OVS but still does not reproduce: > openvswitch-2.9.0-47.el7fdp.2.x86_64 > qemu-kvm-rhev-2.12.0-8.el7.x86_64 > kernel-3.10.0-927.el7.x86_64 > dpdk-17.11-11.el7.x86_64 > > Do you have traffic generator started to reproduce? This issue can be reproduced without traffic generator. In my today's testing, ovs core dump issue is not 100% reproduced. As sometimes qemu crash, sometimes ovs crash(ovs and qemu are not crashed at same time, every time only one of them crash). For qemu crash issue, it should be bug[1]. [1]Bug 1552978 - qemu crash during throughput testing over ovs+dpdk+vhost-user Thanks, Pei Hi Pei, I managed to reproduce the OVS crash on your setup. The reason of the crash is that on Virtio PMD second probe, VHOST_USER_SET_MEM_TABLE request is sent again, but the IOTLB cache is not flushed and so it contains invalid IOTLB entries pointing to unmapped pages in vhost-user process address space. I posted the fix upstream [0], and tested it on you setup. I generated test RPMs in case you are willing to try[1]. About the QEMU crash, I managed to reproduce it once, and I confirm it looks like Bz1552978 (and Bz1547940). Thanks, Maxime [0]: http://patches.dpdk.org/patch/43534/ [1]: http://file.cdg.redhat.com/~mcoqueli/bz1609643/ (In reply to Maxime Coquelin from comment #6) > Hi Pei, > > I managed to reproduce the OVS crash on your setup. > The reason of the crash is that on Virtio PMD second probe, > VHOST_USER_SET_MEM_TABLE request is sent again, but the IOTLB cache > is not flushed and so it contains invalid IOTLB entries pointing > to unmapped pages in vhost-user process address space. > > I posted the fix upstream [0], and tested it on you setup. > I generated test RPMs in case you are willing to try[1]. > About the QEMU crash, I managed to reproduce it once, and I confirm it > looks like Bz1552978 (and Bz1547940). > > Thanks, > Maxime > > [0]: http://patches.dpdk.org/patch/43534/ > [1]: http://file.cdg.redhat.com/~mcoqueli/bz1609643/ Maxime, thank you for handling this issue so quickly. Now this bug can not be reproduced any more with above versions. Tried above steps on 2 different hosts, each for 5 times, ovs always work well. So this issue has been fixed very well. The QEMU crash issue is hard to reproduce, however it still can be reproduced even when testing with above openvswitch-2.9.0-58.bz1609643.el7fdn.x86_64. I'll add coredump info in Bz1552978. Best Regards, Pei Patch applied in usptream's master:
commit af53db486792f3d864c9a30dc13ee12402994640
Author: Maxime Coquelin <maxime.coquelin>
Date: Thu Aug 2 19:21:22 2018 +0200
vhost: flush IOTLB cache on new mem table handling
IOTLB entries contain the host virtual address of the guest
pages. When receiving a new VHOST_USER_SET_MEM_TABLE request,
the previous regions get unmapped, so the IOTLB entries, if any,
will be invalid. It does cause the vhost-user process to
segfault.
This patch introduces a new function to flush the IOTLB cache,
and call it as soon as the backend handles a VHOST_USER_SET_MEM
request.
Fixes: 69c90e98f483 ("vhost: enable IOMMU support")
Cc: stable
Signed-off-by: Maxime Coquelin <maxime.coquelin>
Reviewed-by: Tiwei Bie <tiwei.bie>
Reviewed-by: Jens Freimann <jfreimann>
Verification: Versions: openvswitch-2.9.0-59.el7fdn.x86_64 3.10.0-933.el7.x86_64 tuned-2.9.0-1.el7.noarch qemu-kvm-rhev-2.12.0-10.el7.x86_64 dpdk-17.11-10.el7fdb.x86_64 libvirt-4.5.0-6.el7.x86_64 Steps: 1. Do same testings as Description, ovs keeps working well. 3/3 PASS 2. Do live migration with vIOMMU, ovs keeps working well. 10/10 PASS So this issue has been fixed very well. Move to 'VERIFIED' as comment 10. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:3500 |
Created attachment 1471414 [details] Guest XML Description of problem: This is testing with enabling vIOMMU support. Boot ovs, then boot VM. Start testpmd in guest, then kill it, start it again will cause ovs-vswitchd segfault. Version-Release number of selected component (if applicable): openvswitch-2.9.0-55.el7fdp.x86_64 3.10.0-927.el7.x86_64 qemu-kvm-rhev-2.12.0-8.el7.x86_64 libvirt-4.5.0-4.el7.x86_64 tuned-2.9.0-1.el7.noarch dpdk-17.11-10.el7fdb.x86_64 How reproducible: 100% Steps to Reproduce: 1. Boot ovs, refer to[1] 2. Boot VM, full xml is attached. 3. Start testpmd in guest, refer to[3] 4. Destroy testpmd # ps aux | grep testpmd root 1653 370 0.8 4406036 70496 pts/0 SLl+ 13:33 3:34 /usr/bin/testpmd -l 1,2,3,4,5 -n 4 -d /usr/lib64/librte_pmd_virtio.so.1 -w 0000:06:00.0 -w 0000:07:00.0 -- --nb-cores=4 --disable-hw-vlan -i --disable-rss --rxq=2 --txq=2 ... # kill -9 1653 5. Start testpmd again, refer to[5], ovs segfault. # dmesg (in host) ... [11531.550929] ovs-vswitchd[11947]: segfault at 2ab07ffb1002 ip 0000557a3552d360 sp 00007f5a037fd4d0 error 4 in ovs-vswitchd[557a3533b000+4b8000] Actual results: Guest testpmd operations can cause host ovs crash. Expected results: ovs should not crash. Reference: [1] # cat boot_ovs_client.sh #!/bin/bash set -e echo "killing old ovs process" pkill -f ovs-vswitchd || true sleep 5 pkill -f ovsdb-server || true echo "probing ovs kernel module" modprobe -r openvswitch || true modprobe openvswitch echo "clean env" DB_FILE=/etc/openvswitch/conf.db rm -rf /var/run/openvswitch mkdir /var/run/openvswitch rm -f $DB_FILE echo "init ovs db and boot db server" export DB_SOCK=/var/run/openvswitch/db.sock ovsdb-tool create /etc/openvswitch/conf.db /usr/share/openvswitch/vswitch.ovsschema ovsdb-server --remote=punix:$DB_SOCK --remote=db:Open_vSwitch,Open_vSwitch,manager_options --pidfile --detach --log-file ovs-vsctl --no-wait init echo "start ovs vswitch daemon" ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-socket-mem="1024,1024" ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-lcore-mask="0x1" ovs-vsctl --no-wait set Open_vSwitch . other_config:vhost-iommu-support=true ovs-vswitchd unix:$DB_SOCK --pidfile --detach --log-file=/var/log/openvswitch/ovs-vswitchd.log echo "creating bridge and ports" ovs-vsctl --if-exists del-br ovsbr0 ovs-vsctl add-br ovsbr0 -- set bridge ovsbr0 datapath_type=netdev ovs-vsctl add-port ovsbr0 dpdk0 -- set Interface dpdk0 type=dpdk options:dpdk-devargs=0000:04:00.0 ovs-vsctl add-port ovsbr0 vhost-user0 -- set Interface vhost-user0 type=dpdkvhostuserclient options:vhost-server-path=/tmp/vhostuser0.sock ovs-ofctl del-flows ovsbr0 ovs-ofctl add-flow ovsbr0 "in_port=1,idle_timeout=0 actions=output:2" ovs-ofctl add-flow ovsbr0 "in_port=2,idle_timeout=0 actions=output:1" ovs-vsctl --if-exists del-br ovsbr1 ovs-vsctl add-br ovsbr1 -- set bridge ovsbr1 datapath_type=netdev ovs-vsctl add-port ovsbr1 dpdk1 -- set Interface dpdk1 type=dpdk options:dpdk-devargs=0000:04:00.1 ovs-vsctl add-port ovsbr1 vhost-user1 -- set Interface vhost-user1 type=dpdkvhostuserclient options:vhost-server-path=/tmp/vhostuser1.sock ovs-ofctl del-flows ovsbr1 ovs-ofctl add-flow ovsbr1 "in_port=1,idle_timeout=0 actions=output:2" ovs-ofctl add-flow ovsbr1 "in_port=2,idle_timeout=0 actions=output:1" ovs-vsctl set Open_vSwitch . other_config={} ovs-vsctl set Open_vSwitch . other_config:dpdk-lcore-mask=0x1 ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x15554 ovs-vsctl set Interface dpdk0 options:n_rxq=2 ovs-vsctl set Interface dpdk1 options:n_rxq=2 echo "all done" # sh boot_ovs_client.sh # ovs-vsctl show 9b34b335-067e-493e-bc00-d8ba41e0c82d Bridge "ovsbr1" Port "vhost-user1" Interface "vhost-user1" type: dpdkvhostuserclient options: {vhost-server-path="/tmp/vhostuser1.sock"} Port "dpdk1" Interface "dpdk1" type: dpdk options: {dpdk-devargs="0000:04:00.1", n_rxq="2"} Port "ovsbr1" Interface "ovsbr1" type: internal Bridge "ovsbr0" Port "ovsbr0" Interface "ovsbr0" type: internal Port "dpdk0" Interface "dpdk0" type: dpdk options: {dpdk-devargs="0000:04:00.0", n_rxq="2"} Port "vhost-user0" Interface "vhost-user0" type: dpdkvhostuserclient options: {vhost-server-path="/tmp/vhostuser0.sock"} [3] # modprobe vfio # modprobe vfio-pci # echo 4 > /sys/devices/system/node/node0/hugepages/hugepages-1048576kB/nr_hugepages # dpdk-devbind --bind=vfio-pci 0000:06:00.0 # dpdk-devbind --bind=vfio-pci 0000:07:00.0 # /usr/bin/testpmd \ -l 1,2,3,4,5 \ -n 4 \ -d /usr/lib64/librte_pmd_virtio.so.1 \ -w 0000:06:00.0 -w 0000:07:00.0 \ -- \ --nb-cores=4 \ --disable-hw-vlan \ -i \ --disable-rss \ --rxq=2 --txq=2 testpmd> start [5] # /usr/bin/testpmd \ -l 1,2,3,4,5 \ -n 4 \ -d /usr/lib64/librte_pmd_virtio.so.1 \ -w 0000:06:00.0 -w 0000:07:00.0 \ -- \ --nb-cores=4 \ --disable-hw-vlan \ -i \ --disable-rss \ --rxq=2 --txq=2 testpmd> start Additional info: