On Thu, Oct 10, 2019 at 11:32 AM Jerin Jacob <jerinjac...@gmail.com> wrote: > > > > On Thu, 10 Oct, 2019, 4:58 AM Stephen Hemminger, <step...@networkplumber.org> > wrote: >> >> On Tue, 8 Oct 2019 20:58:27 +0530 >> Jerin Jacob <jerinjac...@gmail.com> wrote: >> >> > On Tue, 8 Oct, 2019, 8:42 PM Stephen Hemminger, >> > <step...@networkplumber.org> >> > wrote: >> > >> > > On Fri, 6 Sep 2019 14:42:30 +0530 >> > > <vattun...@marvell.com> wrote: >> > > >> > > > From: Vamsi Attunuru <vattun...@marvell.com> >> > > > >> > > > The DPDK use case such as VF representer or OVS offload etc >> > > > would call for PF and VF PCIe devices to bind vfio-pci >> > > > module to enable IOMMU protection. >> > > > >> > > > In addition to vSwitch use case, unlike, other PCI class of >> > > > devices, Network class of PCIe devices would have additional >> > > > responsibility on the PF devices such as promiscuous mode support >> > > > etc. >> > > > >> > > > The above use cases demand VFIO needs bound to PF and its >> > > > VF devices. This is use case is not supported in Linux kernel, >> > > > due to a security issue where it is possible to have >> > > > DoS in case if VF attached to guest over vfio-pci and netdev >> > > > kernel driver runs on it and which something VF representer >> > > > would like to enable it. >> > > > >> > > > Since we can not differentiate, the vfio-pci bounded VF devices >> > > > runs DPDK application or netdev driver in guest, we can not >> > > > introduce any scheme to fix DoS case and therefore not have >> > > > proper support of this in the upstream kernel. >> > > > >> > > > The igb_uio enables such PF and VF binding support for >> > > > non-iommu devices to make VF representer or OVS offload >> > > > run on non-iommu devices with DoS vulnerability for netdev driver >> > > > as VF. >> > > > >> > > > This kernel module, facilitate to enable SRIOV on PF devices, >> > > > therefore, to run both PF and VF devices in VFIO mode knowing >> > > > its impacts like igb_uio driver functions of non-iommu devices. >> > > > >> > > > Signed-off-by: Vamsi Attunuru <vattun...@marvell.com> >> > > > Signed-off-by: Jerin Jacob <jer...@marvell.com> >> > > >> > > NAK >> > > Having kernel drivers not in upstream kernel is a long term >> > > maintenance and security risk. Please work with upstream kernel >> > > developers to get this merged there. >> > > >> > >> > There is security issue in attaching DPDK PF driver and netdev bind to VF. >> > So this scheme is not upsteamble to Linux kernel. Since rte_flow had VF >> > action. We need this scheme to support VF action with VFIO. So, Out of tree >> > is the only way as it is DPDK specific feature. Already sent patches to >> > Linux kernel, it make sense to not accept this in upstream. We are already >> > exposing such features through igb-uio for non VFIO device. IMO, there >> > should not be any disparity between igb-uio and VFIO in DPDK. >> > >> > If we are against out of tree module, let's remove igb-uio as well. We >> > can't have different treatment for similar issues. >> >> You are right igb-uio is legacy and only exists for users unwilling to >> change (such as old kernels which don't support vfio noiommu mode). > > > It is NOT completely correct. This specific use case (allowing PF to bind > DPDK and VF to have netdev in non VFIO mode allowed by igb-uio) now. So all > non upsteamble features are going through igb-uio. That's is the main reason > why igb-uio exist. > > > >> Eventually it should go as well. And the same for KNI. > > > > Nothing works without timeline. If that's the plan then decide the > timeline.Please... > > >> >> Understand the pain, but this feels like a child who gets a no >> answer from one parent and therefore thinks they can ask the other parent >> and get a yes. >> >> Who is the person in the upstream kernel community that needs to understand >> what is needed. Maybe another "I know what I am doing" kernel flag is needed >> like no-iommu mode has. > > > no-iommu case is different where we cannot screw Linux netdev driver, you can > create a damage to your self that's an acceptable compromise. > > In this case, when DPDK PF bound application dies then it will impact netdev > VF driver as gets stalled and there is a security issues to VF netdev driver > that DPDK PF can intersect the netdev VF mailbox message. > > So this case is different where from Kernel PoV there is damange to netdev VF > so this can not be accepted in Linux. > > One option is to add this piece of code igb-uio instead to adding new driver. > What do you say? > > It is the problem for all non bifurcated drivers in DPDK not specific to > Marvell. > > The workaround is to use igb-uio with non VFIO. > We can not support UIO through performance reason hence we need a solution > that works for VFIO due to HW accelerated mempool architecture (applicable > for all NPU) > > We can not have VFIO vs UIO specific features disparity in DPDK. Please have > same treatment. Either remove igb-uio hacks from Dpdk or enable non > upsteamble features through igb-uio.So that there is no disparity for a > specific use case / vendor.
Andrew Rybchenko already acked this patch and I provided enough data on the need for this patch. I hope there is no more confusion about the need for this patch.
