2015-03-31 11:35 GMT+02:00 Burakov, Anatoly <anatoly.burakov at intel.com>: > > > I think the whole process of VFIO binding maybe needs at least a second > > thought regarding corner cases and security. > > > > 1) in the setup process, there currently is no mechanism that checks if the > > Device to be used has other devices in the > > same iommu group that need to be bound to VFIO too. Otherwise using VFIO > > will fail. > > I think currently, it only works if the network device is the only one in > > its iommu group. > > > > 2) Right now everything inside /dev/vfio/ is granted to the all users, > > right? Maybe this leads to (security) issues if VFIO > > is in active use by other non-dpdk processes for other PCIe devices. > > I believe that's how VFIO is meant to be used. At least according to VFIO > documentation, located here: https://www.kernel.org/doc/Documentation/vfio.txt > > Regarding 1), this can only be done by unbinding the device from the host > driver and binding it to vfio-pci, which can't be done by the user. If the > device is not bound to vfio-pci, we have no way of knowing if it belongs to > this or that IOMMU group.
iommu groups already exist before vfio-pci is loaded. The whole setup process as described in the VFIO documentation, where a PCIe device shares an iommu group with other devices, can therefore be automated. Some time ago I wrote a ruby script that does exactly that (https://github.com/andre-richter/rVFIO/blob/master/example/pci-bind.rb). Porting it to bash should be no problem. However, the question is if dpdk needs to cover this (corner?) case. I would assume that the bulk of dpdk use-cases deals with scenarios where the targeted NIC is the only one in its iommu group, because it is a high-speed NIC that is connected to a CPU-integrated PCIe-Port. A NIC sharing an iommu group with other devices would be most likely if it is behind a bridge, aka a chipset-integrated NIC or a NIC that resides in a PCIe-Slot that connects to the chipset. This is more common in desktop machines than in server grade machines. Cheers, Andre > > Regarding 2), as noted above, the administrator should set up VFIO devices. > While I agree that the way setup.sh sets up VFIO security permissions is not > ideal, it's really there to cover the most common use case. An administrator > can always set up VFIO on his own, granting permissions as needed. > > Thanks, > Anatoly
