From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 99DE4A3160 for <public@inbox.dpdk.org>; Thu, 10 Oct 2019 01:28:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B20B71E535; Thu, 10 Oct 2019 01:28:40 +0200 (CEST) Received: from mail-pl1-f193.google.com (mail-pl1-f193.google.com [209.85.214.193]) by dpdk.org (Postfix) with ESMTP id 63D521C1E1 for <dev@dpdk.org>; Thu, 10 Oct 2019 01:28:39 +0200 (CEST) Received: by mail-pl1-f193.google.com with SMTP id j11so1815506plk.3 for <dev@dpdk.org>; Wed, 09 Oct 2019 16:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=mMRUAgBdMNVmceWf1Txoq3TVsZq685VCPB/vKYQbqYc=; b=e7Q3xKN3oXN9qI6jkujR0ccQEmaBaTH07hVlNO53KZxqNfUPKAPeGpzvf+cXdTdJcq DDwyWChTVzsXM6tF4YosnZLSjj34WclQpJ0Svl5PpJTFRngobfZTTnmDkk2C2FZ9xOUG gy0a5InoVkn9b16/i27Mapw2Q5HeY46l4D1/lSZ3YNsoCQXRrDC5pb6K3nsCZwg2CTUp BQpWrM/nl92alqUdUlBZ7CjGcUaGUnVourCcc9IhBYdAjnX1tp2BTjOiLNoKbcIkpU3c Ur9gMwm+KZqYcwzeLpSKSsVjAlC+0x+KR6SRotkg9HTudKOnJ6RIZVmyd7gx2rwEFRfH i5tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=mMRUAgBdMNVmceWf1Txoq3TVsZq685VCPB/vKYQbqYc=; b=jJXN3oqYn0Gtqms5VAMJ8TRFTZ5FDq14D1SmcbzHf7SxIsawsWrVMjqD53gAsL086j dt8wnQld7qRWJdNCPWo9GDMLCaw0iXHynslu6Wt7HX7YtGPyM+gCzLGfoUeOE1hGnxLb 8T9c8drDHdoVw3vD1Kua7bv4UJ7XgCw45RS2tkN0mMqL3TBsRjCsfSKI4m/UbJ7/Zpla s45KEpwlhsK782pd8J02RS6huO3+BEo4harUXYv4WZ0zeJ6WTS7f0ydONZM/jpojifUW keBR9UZWeUVp+D9x6sFMxexI3ENp2q0vEeegJI/i6QpNoI0KkppXtgTphZhem4K5pbFY 4Tpg== X-Gm-Message-State: APjAAAUbtIYkfbR3ilPkQFpVwup88dnOX7U7hK66nsYsbrs1kGFK34+9 ZqTt1+C5/NzL7BC7M8JI2XevTg== X-Google-Smtp-Source: APXvYqye2nYiGzOk1rz0zYCBda2RvYCU91pwx7/r9SkO4ywZB2MhVn8P+1ksnwFLCTADiDlhRu/cvg== X-Received: by 2002:a17:902:8690:: with SMTP id g16mr5627247plo.294.1570663718347; Wed, 09 Oct 2019 16:28:38 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id r21sm3339646pgm.78.2019.10.09.16.28.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Oct 2019 16:28:38 -0700 (PDT) Date: Wed, 9 Oct 2019 16:28:31 -0700 From: Stephen Hemminger <stephen@networkplumber.org> To: Jerin Jacob <jerinjacobk@gmail.com> Cc: Vamsi Attunuru <vattunuru@marvell.com>, dpdk-dev <dev@dpdk.org>, thomas@monjalon.net, jerinj@marvell.com Message-ID: <20191009162831.0c1cf204@hermes.lan> In-Reply-To: <CALBAE1NUaKwWqdktC3PJSJ_qaRtFHobahruTyVKUWZNXSPwveA@mail.gmail.com> References: <20190906091230.13923-1-vattunuru@marvell.com> <20191008081244.425551a0@hermes.lan> <CALBAE1NUaKwWqdktC3PJSJ_qaRtFHobahruTyVKUWZNXSPwveA@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On Tue, 8 Oct 2019 20:58:27 +0530 Jerin Jacob <jerinjacobk@gmail.com> wrote: > On Tue, 8 Oct, 2019, 8:42 PM Stephen Hemminger, <stephen@networkplumber.org> > wrote: > > > On Fri, 6 Sep 2019 14:42:30 +0530 > > <vattunuru@marvell.com> wrote: > > > > > From: Vamsi Attunuru <vattunuru@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 <vattunuru@marvell.com> > > > Signed-off-by: Jerin Jacob <jerinj@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). Eventually it should go as well. And the same for KNI. 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.