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 0305EA2EFC for ; Sun, 13 Oct 2019 09:20:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7A1E61C2F1; Sun, 13 Oct 2019 09:20:37 +0200 (CEST) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by dpdk.org (Postfix) with ESMTP id 796B31C2B4 for ; Sun, 13 Oct 2019 09:20:35 +0200 (CEST) Received: by mail-io1-f67.google.com with SMTP id n26so30255888ioj.8 for ; Sun, 13 Oct 2019 00:20:35 -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=s2V+XvardaL0TgGFJN+Nz8lig+Ffe0h5aXPggizvMuE=; b=GhCtY3xmwIxMjkHxltme9UsHRcaogLn6oJ/JCLWftU18pgsF8lQX9OaueXLMhN8j4Y Pu72Ox5kwBMGowIU8p8s9koxh/z8quad99f4jOOAlTtevyVIPy+M7yDBYTDb4zmRsRkQ qZU/UFUe/xNkv6DDSGZ7xmvP0hJgdjdRI3rtAH49Pqx7VlP030XCpTLNAfDMURPbIJWd hSoGC8Y/c/glfEHJTG8+mpfEifRr3e9S607sSV9h56SuriAziqAbdxgdE+za6WenTb2K DKjSkcAIk07kae9fTBweSWIV3dvWxhxTF7SqaYCmGIVhy0qT3zLGzmQCk5/FxIqj5e98 J8sw== 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=s2V+XvardaL0TgGFJN+Nz8lig+Ffe0h5aXPggizvMuE=; b=D+y8yPNnyNxGT+cKtH4tbAAOvVHfFfkE/i6f2Ykk9XhgodvJwU2jAwsIkfSfURZ+dY BC6pqF7uAJBxhGSVF5NLiplc97g76n+i/aoKDjIf23Zr5pg9zvn7sNSjEjY8h1MTOdQf oYficDU8br6IPuP+W0TyBnmWHie6xdwzBIvHZskeyM2wSgZX+lbJ5QnWLsvYDpA/fp1p B5gruA/sD0hW4SxVb/B3titNESqx9C7Jao9eo24yCxTiwB5kTLKeVN1pj2irxw+sV0Kt zby4GhPM1RDM+rSuQp7YAoL62lFlEE+LhoVmTdTg7ac8Ph4K4b6d/seMjx4+wXwpCJoz ITfA== X-Gm-Message-State: APjAAAXujg3EgE+szs6a5YA1dM1OtQuv0mOruL39U4QgJm0pfKxU2Zhd 7lZt8kRVPnuydKcQjtK0P+Hti3CUiTYnZBtg89g= X-Google-Smtp-Source: APXvYqyCpOFB1UsSb4O8trVjZ4qGqLTGp8mWuZh9vTpd6v8cdpPtNJWI7NB5iRHYy3umsfZLff3ca++qOR2Nb40uILk= X-Received: by 2002:a5d:8cc6:: with SMTP id k6mr26597766iot.15.1570951234392; Sun, 13 Oct 2019 00:20:34 -0700 (PDT) MIME-Version: 1.0 References: <20190906091230.13923-1-vattunuru@marvell.com> <20191008081244.425551a0@hermes.lan> <20191009162831.0c1cf204@hermes.lan> In-Reply-To: From: Jerin Jacob Date: Sun, 13 Oct 2019 12:50:23 +0530 Message-ID: To: Stephen Hemminger Cc: Vamsi Attunuru , dpdk-dev , Thomas Monjalon , Jerin Jacob Content-Type: text/plain; charset="UTF-8" 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, Oct 10, 2019 at 11:32 AM Jerin Jacob wrote: > > > > 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, >> > 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. 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.