Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1532956

Summary: Boot guest with vhost-user setting "iommu='on' ats='on'", dpdk's testpmd can not receive packets.
Product: Red Hat Enterprise Linux 7 Reporter: Pei Zhang <pezhang>
Component: openvswitchAssignee: Kevin Traynor <ktraynor>
Status: CLOSED CURRENTRELEASE QA Contact: Pei Zhang <pezhang>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.5CC: atragler, chayang, ctrautma, hewang, juzhang, maxime.coquelin, michen, tli
Target Milestone: rcKeywords: Reopened
Target Release: ---   
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: 2018-02-08 06:50:28 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:
Description Flags
XML of VM none

Description Pei Zhang 2018-01-10 05:30:14 UTC
Created attachment 1379360 [details]
XML of VM

Description of problem:
Boot Guest with vIOMMU over openvswitch-dpdk. Guest's dpdk's testpmd can not receive packets.


Version-Release number of selected component (if applicable):
qemu-kvm-rhev-2.10.0-16.el7.x86_64
3.10.0-827.el7.x86_64
openvswitch-2.9.0-0.3.20171212git6625e43.el7fdb.x86_64
dpdk-17.11-4.el7.x86_64
libvirt-3.9.0-7.el7.x86_64


How reproducible:
100%

Steps to Reproduce:
1. Boot ovs, refer to[1]

2. Boot VM with vhostuser, set "iommu='on' ats='on'" like below, full XML please refer to the attachment.

    <interface type='vhostuser'>
      <mac address='88:66:da:5f:dd:02'/>
      <source type='unix' path='/tmp/vhostuser0.sock' mode='server'/>
      <model type='virtio'/>
      <driver name='vhost' queues='2' iommu='on' ats='on'/>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </interface>
  
3. In guest, load vfio and start testpmd
# modprobe vfio
# modprobe vfio-pci 

# /usr/bin/testpmd \
-l 1,2,3,4,5 \
-n 4 \
-d /usr/lib64/librte_pmd_virtio.so.1 \
-w 0000:03:00.0 -w 0000:04:00.0 \
-- \
--nb-cores=4 \
--disable-hw-vlan \
-i \
--disable-rss \
--rxq=2 --txq=2


4. Start MoonGen in another host, testpmd can not receive packets.


Actual results:
dpdk's testpmd can not receive packets with vIOMMU.

Expected results:
dpdk's testpmd should receive packets with vIOMMU.

Additional info:
1. If remove "iommu='on' ats='on'", other XML keep same, everything will work well, guest can receive packets.

Note: As in https://bugzilla.redhat.com/show_bug.cgi?id=1283104#c4, to enable the iommu for vitio-net-pci, qemu needs to specify iommu_platform=on,ats=on. So these two options are needed if we test with vIOMMU.

2. I'm not quit sure what need to do to enable vIOMMU from openvswitch side, so maybe there is some options missed when booting openvswitch. Please refer to[2] to check the script I used.


Reference:
[1]
# ovs-vsctl show
31294641-c0f4-4489-ac78-f179cfffc573
    Bridge "ovsbr1"
        Port "dpdk1"
            Interface "dpdk1"
                type: dpdk
                options: {dpdk-devargs="0000:81:00.1", n_rxq="2"}
        Port "vhost-user1"
            Interface "vhost-user1"
                type: dpdkvhostuserclient
                options: {vhost-server-path="/tmp/vhostuser1.sock"}
        Port "ovsbr1"
            Interface "ovsbr1"
                type: internal
    Bridge "ovsbr0"
        Port "vhost-user0"
            Interface "vhost-user0"
                type: dpdkvhostuserclient
                options: {vhost-server-path="/tmp/vhostuser0.sock"}
        Port "dpdk0"
            Interface "dpdk0"
                type: dpdk
                options: {dpdk-devargs="0000:81:00.0", n_rxq="2"}
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal


[2]
#!/bin/bash

set -e

echo "killing old ovs process"
pkill -f ovs- || true
pkill -f ovsdb || 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

#systemctl start openvswitch.service

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-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:81: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:81: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"

echo "all done"

Comment 2 Kevin Traynor 2018-02-07 12:03:26 UTC
Hi Pei, does this work with DPDK as a vswitch in the host? Mostly vhost path in openvswitch is done in the DPDK code.

Perhaps there is some upstream commit missing from the packages you tested with. We use DPDK 17.11.0 in both packages you have tested with.

We have recently backported virt fixes for 1530957, 1450680 & 1525446. You could try the latest packages if one of them is a suspect.

The latest packages are:
openvswitch-2.9.0-0.5.20171212git6625e43.el7fdb https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=651865

and

dpdk-17.11-7.el7
https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=650654

Comment 3 Maxime Coquelin 2018-02-07 12:31:26 UTC
Hi Kevin,

Does this openvswitch package has below patch?

commit a14d1cc8a74858c7488207e02b9ebdb67e50bd88
Author: Mark Kavanagh <mark.b.kavanagh>
Date:   Fri Dec 8 10:53:47 2017 +0000

    netdev-dpdk: vHost IOMMU support
    
    DPDK v17.11 introduces support for the vHost IOMMU feature.
    This is a security feature, which restricts the vhost memory
    that a virtio device may access.
    
    This feature also enables the vhost REPLY_ACK protocol, the
    implementation of which is known to work in newer versions of
    QEMU (i.e. v2.10.0), but is buggy in older versions (v2.7.0 -
    v2.9.0, inclusive). As such, the feature is disabled by default
    in (and should remain so), for the aforementioned older QEMU
    verions. Starting with QEMU v2.9.1, vhost-iommu-support can
    safely be enabled, even without having an IOMMU device, with
    no performance penalty.
    
    This patch adds a new global config option, vhost-iommu-support,
    that controls enablement of the vhost IOMMU feature:
    
        ovs-vsctl set Open_vSwitch . other_config:vhost-iommu-support=true
    
    This value defaults to false; to enable IOMMU support, this field
    should be set to true when setting other global parameters on init
    (such as "dpdk-socket-mem", for example). Changing the value at
    runtime is not supported, and requires restarting the vswitch daemon.
    
    Signed-off-by: Mark Kavanagh <mark.b.kavanagh>
    Acked-by: Kevin Traynor <ktraynor>
    Signed-off-by: Ian Stokes <ian.stokes>


If this is the case, it seems below command is missing in above instructions to enable Vhost IMOOU support in OVS:

ovs-vsctl set Open_vSwitch . other_config:vhost-iommu-support=true

Regards,
Maxime

Comment 4 Kevin Traynor 2018-02-07 13:49:56 UTC
(In reply to Maxime Coquelin from comment #3)
....
> 
> If this is the case, it seems below command is missing in above instructions
> to enable Vhost IMOOU support in OVS:
> 
> ovs-vsctl set Open_vSwitch . other_config:vhost-iommu-support=true
> 

Ah yes, you are right. The commit is in both openvswitch packages mentioned above, so it could be as simple as setting it =true. I forgot about that commit and that it's default off :| Thanks for catching.

Comment 5 Pei Zhang 2018-02-08 05:17:15 UTC
Thanks Kevin and Maxime.

Summary: This bug has been fixed well. Testing OpenvSwitch with vIOMMU, guest testpmd can receive packets and also the throughput results looks good. 

Versions:
3.10.0-845.el7.x86_64
qemu-kvm-rhev-2.10.0-19.el7.x86_64
tuned-2.9.0-1.el7.noarch
libvirt-3.9.0-11.el7.x86_64
openvswitch-2.9.0-0.6.20171212git6625e43.el7fdb.x86_64
dpdk-17.11-7.el7.x86_64

Steps:
Following steps in Description. And the scripts to boot OpenvSwitch is updated like below:
...
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
...

Here is the 0 loss bidirectional throughput results:
                   frame_size   qeueues    throughput
with iommu         64Byte          2        21.307253Mpps
with no-iommu      64Byte          2        21.307355Mpps


So this bug has been fixed very well. Close as 'CURRENTRELEASE'.

 (In reply to Kevin Traynor from comment #2)
> Hi Pei, does this work with DPDK as a vswitch in the host? Mostly vhost path
> in openvswitch is done in the DPDK code.
> 

Kevin, DPDK as a vswitch in the host, everything works well with vIOMMU.


Best Regards,
Pei

Comment 6 Pei Zhang 2018-02-08 05:24:08 UTC
Sorry I noticed that I'm not QA Contact, so I should not change status of this bug, recover it.


Best Regards,
Pei

Comment 7 Pei Zhang 2018-02-08 06:50:28 UTC
As this bug was filed by me and can not reproduce with latest OpenvSwitch. So, I'm taking it and closing it as 'CURRENTRELEASE', please free to reopen if you have any objections.Thanks.