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 0858EA0613 for <public@inbox.dpdk.org>; Wed, 25 Sep 2019 09:19:00 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 98A511B94A; Wed, 25 Sep 2019 09:18:55 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id B40361BDFD for <dev@dpdk.org>; Wed, 25 Sep 2019 09:18:52 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us2.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id ADF57700079; Wed, 25 Sep 2019 07:18:50 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 25 Sep 2019 08:18:44 +0100 To: Vamsi Krishna Attunuru <vattunuru@marvell.com>, Jerin Jacob Kollanukkaran <jerinj@marvell.com>, Thomas Monjalon <thomas@monjalon.net> CC: "dev@dpdk.org" <dev@dpdk.org> References: <20190906091230.13923-1-vattunuru@marvell.com> <1612178.XsdEgM4R2a@xps> <BYAPR18MB2424ACA16BBA9D6387FBA10CC8BA0@BYAPR18MB2424.namprd18.prod.outlook.com> <MWHPR18MB16451F3211EB8704EF6E40C3A6870@MWHPR18MB1645.namprd18.prod.outlook.com> From: Andrew Rybchenko <arybchenko@solarflare.com> Message-ID: <fa2fb2f8-cfb3-ec55-4885-c22fdf6452eb@solarflare.com> Date: Wed, 25 Sep 2019 10:18:40 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <MWHPR18MB16451F3211EB8704EF6E40C3A6870@MWHPR18MB1645.namprd18.prod.outlook.com> Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24932.003 X-TM-AS-Result: No-26.205400-8.000000-10 X-TMASE-MatchedRID: 8HTFlOrbAtHmLzc6AOD8DfHkpkyUphL9OhJ9m53n4aAjRiu1AuxJTPXn V44mE6yUtUM87V453EKS6gaP6V7OWuE1n7m+jMjAcN+LFb07lxgHuUxnhixmT7V5fSMRD1zqiCc t0dTuiI5A5GooFgjK1zHePU1MbHBZTdtgniHdnTnM0ihsfYPMYUYj0zDHPzJpYAwzRYoPhqw9Nc ZcS8Ed2uBizFzQ56dqh/2iKS29zltwwM8VRYBtwE+zv2ByYSDQzPMyzZ3J7JW6Gxh0eXo7a05VH uLzyf0qo9w2C6V6g2DTwojfnIkreKGnquim0WHzAZ0lncqeHqFDfut2Lc1Yh3mvr3EYUSdA4xsb x6pyCsY/uyaZOa0NxikTGeJZVBs5weZT6mugzfHAkT1oCa9sn65BoXfdPww+K8VLPDcP9n5xmpl AleOtpIRwP61eGwAvaYoWVHqV+d0ZYiw1fN5w0WzBijri5+RVm1xhXnxxzmJC/TxbZqlbxzLk8G 2qhCWTbM7BFA9Xf3PK+QFXYp+Gtd6ri2r1oLDLvVl3GmT9KRzG5RpLH3eb4xbozYDXkvVAOSZO4 a90UVDk0NDh6vpy328kbPg9adS4/bzkmiq3kw9xk9SAb2lm0TH+T3YvtHy223K4Yx5Gl8R4tfVZ nXnk3v5UfeZ86kX2CDMOrCtXbF9JH11OOVB0yRbwCXv1ucAPY4m2G5vTtLCo8aocg8ZmI+1+sfr t9AWIe9aLjVRxa1EfmtZCIEnAcoEMot1OSIzbnMQdNQ64xfcSp9rqY6jeEmb1gX+Qx+5tJkpEgW lcD4E5V/Luw7YavR4ind4H9XiUrujapP4CHCWeAiCmPx4NwLTrdaH1ZWqC1B0Hk1Q1KyIc4WL5J jd88CIQ5mZ5SqHPr+8hSfCN+4Zae9x47OblCG1vT7j4yk6W4lrnUdbiG7ZgHCTNWXE0xQ== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--26.205400-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24932.003 X-MDID: 1569395931-oAfRpf07mVI3 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit 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 <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 9/25/19 7:06 AM, Vamsi Krishna Attunuru wrote: > Hi, > > We would like to have these support in 19.11. Please let us know if there are any comments or suggestions, we can discuss and address accordingly. > > -----Original Message----- > From: Jerin Jacob Kollanukkaran <jerinj@marvell.com> > Sent: Friday, September 6, 2019 6:58 PM > To: Thomas Monjalon <thomas@monjalon.net>; Vamsi Krishna Attunuru <vattunuru@marvell.com> > Cc: dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH v1 1/1] kernel/linux: introduce vfio_pf kernel module > >> -----Original Message----- >> From: Thomas Monjalon <thomas@monjalon.net> >> Sent: Friday, September 6, 2019 3:15 PM >> To: Vamsi Krishna Attunuru <vattunuru@marvell.com> >> Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran <jerinj@marvell.com> >> Subject: Re: [dpdk-dev] [PATCH v1 1/1] kernel/linux: introduce vfio_pf >> kernel module >> >> 06/09/2019 11:12, vattunuru@marvell.com: >>> 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> >> Sorry I fail to properly understand the explanation above. >> Please try to split in shorter sentences. >> >> About the request to add an out-of-tree Linux kernel driver, I guess >> Jerin is well aware that we don't want such anymore. > Yes. I am aware of it. I don't like the out of tree modules either. But, This case, I suggested Vamsi to have out of tree module. > > Let me describe the issue and let us discuss how to tackle the problem: > > # Linux kernel wont allow VFIO PF to have SRIOV enable. > > Patches and on going discussion are here: > https://patchwork.kernel.org/patch/10522381/ > https://lwn.net/Articles/748526/ > > Based on my understanding the reason for NOT allowing the VFIO PF to have SRIOV enable is genuine from kernel point of View but not from DPDK point of view. > > Here is the sequence to describe the problem > 1) Consider Linux kernel allowed VFIO PCI SRIOV enable > 2) PF bound to vfio-pci > 3) using SRIOV infrastructure of vfio-pci PF driver, VFs are created > 4) DPDK application bound to PF and VF, No issue here. > 5) Assume DPDK application bound to PF and VF bound To netdev kernel driver. Now, there is a genuine concern From kernel point of view that, DPDK PF can intercept, VF mailbox message or so and deny the Kernel request Or what if DPDK PF application crashes? > > To avoid the case (5), (3) is not allowed in stock kernel. > Which makes sense IMO. > > Now, From DPDK PoV, step 5 is valid as we have Rte_flow's VF action etc used to enable such case. > Where, user can program the PF's rte_flow to steer Some traffic to VF, where VF can be, DPDK application or Linux kernel netdev driver. > > This patch enables the step (3) to enable step (5) from DPDK PoV. i.e DPDK needs to allow PF to bind to DPDK with VFs. > > Why this issue now: > - igb_uio kernel driver is used as enabling step (3) See store_max_vfs() kernel/linux/igb_uio/igb_uio.c This is fine for non-iommu device, IOMMU devices needs VFIO. > - We would like support VFIO for IOMMU protection And enable step (5) as DPDK supports form the spec level. > i.e need to fix feature disparity between iommu vs non-iommu based devices. > > Note: > We may not need a brand new kernel module, we could move this logic to igb_uio if maintenance is concern. It is really a problem for not bifurcated drivers and I agree with Jerin above. One driver could be better, but I'm not sure and I'm afraid it will make too many changes in igb_uio and result in instabilities/bugs. I have no strong opinion if we can take the risk with igb_uio - simply have no enough information if it is widely used or Linux in-kernel drivers are preferred. Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>