summaryrefslogtreecommitdiffstats
path: root/src/plugins/dhcp/test/vpp_dhcp.py
diff options
context:
space:
mode:
authorYulong Pei <yulong.pei@intel.com>2019-10-17 18:41:52 +0800
committerDamjan Marion <dmarion@me.com>2019-10-20 19:31:14 +0000
commit45495480c8165090722389b08075df06ccfcd7ef (patch)
tree6615491848b31e442422e318ed1c2939b99950cd /src/plugins/dhcp/test/vpp_dhcp.py
parent349cd1af77a27962e9475e9fa9c0ed15e2af23de (diff)
vlib: linux: fix wrong iommu_group value issue when using dpdk-plugin
When VPP work with dpdk-plugin, linux_vfio_main_t->container_fd is always -1 since it never have chance to run open("/dev/vfio/vfio") to get the fd. But this lead to a potential issue of VPP, that is, when start VPP without uio-driver field setup in /etc/vpp/startup.conf, VPP will run to automatical select uio driver in vlib_pci_bind_to_uio() and the function depend on iommu_group value to decide to work on vfio or vfio-noiommu mode. Since in vlib_pci_get_device_info() have the condition container_fd != -1, so the iommu_group value will be always -1 at this scenario, this caused that VPP mistake to run with vfio-noiommu driver on intel_iommu=on state. Actually in order to get iommu_group and iommu_group/name value, no need to depend on linux_vfio_main_t->container_fd value, so the fix remove the condition lvm->container_fd != -1, then it can get the correct iommu_group value. Type: fix Change-Id: I3f162fc4971b9a2b8717205f8f3b52e30c5e5b69 Signed-off-by: Yulong Pei <yulong.pei@intel.com>
Diffstat (limited to 'src/plugins/dhcp/test/vpp_dhcp.py')
0 files changed, 0 insertions, 0 deletions