From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0814AA3160 for ; Thu, 10 Oct 2019 08:05:05 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D535C1E8F5; Thu, 10 Oct 2019 08:05:04 +0200 (CEST) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by dpdk.org (Postfix) with ESMTP id 95B001E8EE for ; Thu, 10 Oct 2019 08:05:03 +0200 (CEST) Received: by mail-io1-f65.google.com with SMTP id u8so11086047iom.5 for ; Wed, 09 Oct 2019 23:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yWisQ5iQtJYu7jvIJu38uMAT0eBnVEiDjv3388NUJb8=; b=K71WABIRK32lGvsI2EOFVN1CvJBeAZAVSAS1pwQZHovj4Uuqsvd/9xZ4Cc4XvvAqiB c/JNyeE1O8tF1VOfXVV/Kr69K48eMjfp1YmQEeh7oSctAkRuPHR1pmIhqeD2NVtshshO 9lSCysgiv5zKCcVBn0khTliOHNIgbck14dqJ0/t1R5BBuH+DAZ8szA5CFr9PH/3Y4dfS /BOV+4L7Grk2viN24YuD9y+6Y3U+3myIYzbtmWXpnwpnRrRoJO7zyXe+W5MsejzBu1CA c22S2TQ60OjwmufP99dlW2ClGonGUiCzYp221ZxURJiRWdqlaQ+t8t22Uqm063bYXF6F BRgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yWisQ5iQtJYu7jvIJu38uMAT0eBnVEiDjv3388NUJb8=; b=G4HTvm2Fo29pCuf4epMPLH76NxT3FIcsmF+lmglPpEuUlirKn/cv4g3X8wLbVTx8So R9iMsoMD0PcalIuJUjoXZlbgKWpOp2BTOp9ejcnR2E3hjF3kdski0ScaEiTicgY5j95l oivf1Q7gAbAB25GwUS9tBT0qlYy20FMWypceVhSoW5d24sEPoQg727a+Y7AP7uEsKqOA HENuHsdeynk5gK7Bnnn2uh66DRhFVSi+HdaodI8Xm1yVgDO2NuLxJAvM2NsIt9jwnf0V DLZv11eSNc34G/X6om7hMho3ROlekZtv9NDsUP7rUVvOx4hFbHvs4NyjGDw4+O502ac+ nDIA== X-Gm-Message-State: APjAAAVV+snFd4EIolDaywKS8Ne6SLoeKyjW4/RgzlJ4oUa6lsMMyyQk 4cSflxuOIEKnXohVW5qTXXORIDQ+6UL92sITVlk= X-Google-Smtp-Source: APXvYqyhSdrQQu4ozgb1SKteQIUEeBqzs4ilZuv0oM0OOJblSO2KkvYAPrDzn2GdkjWBcvZq14yKYjX+T3Px6ffWF5s= X-Received: by 2002:a05:6638:a1b:: with SMTP id 27mr5148790jan.102.1570687502618; Wed, 09 Oct 2019 23:05:02 -0700 (PDT) MIME-Version: 1.0 References: <20190906091230.13923-1-vattunuru@marvell.com> <20191008081244.425551a0@hermes.lan> <20191009162831.0c1cf204@hermes.lan> In-Reply-To: <20191009162831.0c1cf204@hermes.lan> From: Jerin Jacob Date: Thu, 10 Oct 2019 11:32:19 +0530 Message-ID: To: Stephen Hemminger Cc: Vamsi Attunuru , dpdk-dev , thomas@monjalon.net, jerinj@marvell.com Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v1 1/1] kernel/linux: introduce vfio_pf kernel module X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, 10 Oct, 2019, 4:58 AM Stephen Hemminger, wrote: > On Tue, 8 Oct 2019 20:58:27 +0530 > Jerin Jacob wrote: > > > On Tue, 8 Oct, 2019, 8:42 PM Stephen Hemminger, < > stephen@networkplumber.org> > > wrote: > > > > > On Fri, 6 Sep 2019 14:42:30 +0530 > > > wrote: > > > > > > > From: Vamsi Attunuru > > > > > > > > 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 > > > > Signed-off-by: Jerin Jacob > > > > > > 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. >