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 9E0AAA04AB; Thu, 7 Nov 2019 06:02:30 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E78C61E56E; Thu, 7 Nov 2019 06:02:29 +0100 (CET) Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by dpdk.org (Postfix) with ESMTP id 16BDD1E568 for ; Thu, 7 Nov 2019 06:02:29 +0100 (CET) Received: by mail-il1-f196.google.com with SMTP id a7so214210ild.6 for ; Wed, 06 Nov 2019 21:02:28 -0800 (PST) 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=m1jCdfbuAdgqU1KrtPjTsZ6PNk3F2v7P/u1nNNLQYJg=; b=foZG8CjbtAa6/sGic+e2XE1Co8jUtFQH5BDT7W5oVptJOHUyroG1bZf5RJ7lrk89fS CdTBjwlhGQYddM4rvwA4SfIvZrEyEFvU2XgxOyEUN6sh6hpXOrjbccTTATLfk0bgs1hp Iu0V4UVKjsscNgBV0h/dtUDvtHoqrAuqfhgHSRCAhM5/0oRNZ3qBlEHsS2RZJwPHyBw/ Z9sKBBrbQ2pJAQktt1gAWKJ8WQiAO8aWJ6iHGgSwj6CPgoV/QY3pJFVfwyzOGeysA9Ky yqbi1KF/pHYkwrVQeUMLJzI2KG97gFlkyAtoABIzsBzhjynllzgTFkOHdKVr1HdyUB2C rE9g== 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=m1jCdfbuAdgqU1KrtPjTsZ6PNk3F2v7P/u1nNNLQYJg=; b=beVYhqhUZx3h+O2n8lXfekj44hHMXLzTigh8XNZcTOO7LUWZWJ56MZM5wXSSoEBrHy KJeRG+Xm5vfaGBO+HK5caAR00I+zmXAvBkryMo7Ow7p44QoD3INaBptDDdwk0CsAQWMZ qrvP2T9JqI3G69ZyhsTzN3hJtK3nEe+/rmhziD2ynuJe79GU71xI8ltvDzbeXmjA3XKh WOCUIPHcVfxG12KxD1ML9eSbYDQ6tXWA9IqVVvOCb0cDPJ3cTmqRwzK2q/O8Ei8LPc50 am4jQGpWYf/JQjLHqF6tFvgd/RRlkwNH2C0l3SE+UVrEA04SC81WZcrA3hUGD6RKRfgb y+tA== X-Gm-Message-State: APjAAAUVL4y+z0/LMWTznzPSqH1RCu5rRtJ90NrFKp0XFKZtoTvcOe5q pPw+nZWXy6AvwNseXrtSlviZwmadzu/nsopwIjg= X-Google-Smtp-Source: APXvYqz6IPHGmZZ1otIjMSy1uGnozITuM/NLXa17AP52jm0T1umreRarkE+LIqGM1RzsmeT/Zs63E386RPcFcLf5QDE= X-Received: by 2002:a92:afd5:: with SMTP id v82mr1964580ill.294.1573102948125; Wed, 06 Nov 2019 21:02:28 -0800 (PST) MIME-Version: 1.0 References: <20190906091230.13923-1-vattunuru@marvell.com> <1612178.XsdEgM4R2a@xps> <1659615.GCIDYkGxRJ@xps> <20191106153250.77e63a38@x1.home> In-Reply-To: <20191106153250.77e63a38@x1.home> From: Jerin Jacob Date: Thu, 7 Nov 2019 10:32:12 +0530 Message-ID: To: Alex Williamson Cc: Thomas Monjalon , dpdk-dev , Jerin Jacob Kollanukkaran , Vamsi Krishna Attunuru , Andrew Rybchenko , Ferruh Yigit , maxime.coquelin@redhat.com, Stephen Hemminger , "Richardson, Bruce" , David Marchand , Luca Boccassi , Christian Ehrhardt , Kevin Traynor , Anatoly Burakov , "Ananyev, Konstantin" , Honnappa Nagarahalli , Liang-Min Wang , Alexander Duyck , Peter Xu , Eric Auger 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, Nov 7, 2019 at 4:03 AM Alex Williamson wrote: > > On Thu, 31 Oct 2019 18:03:53 +0100 > Thomas Monjalon wrote: > > > We don't get enough attention on this topic. > > Let me rephrase the issue and the proposals with more people Cc'ed. > > > > We are talking about SR-IOV VFs in VMs > > with a PF managed on the host by DPDK. > > The PF driver is either a (1) bifurcated (Mellanox case), > > or (2) bound to UIO with igb_uio, or (3) bound to VFIO. > > > > In case 1, the PF is still managed by a kernel driver, so no issue. > > > > In case 2, the PF is managed by UIO. > > There is no SR-IOV support in upstream UIO, > > but the out-of-tree module igb_uio works. > > However we would like to drop this legacy module from DPDK. > > Some (most) Linux distributions do not package igb_uio anyway. > > The other issue is that igb_uio is using physical addressing, > > which is not acceptable with OCTEON TX2 for performance reason. > > > > In case 3, the PF is managed by VFIO. This is the case we want to fix. > > VFIO does not allow to create VFs. > > The workaround is to create VFs before binding the PF to VFIO. > > But since Linux 4.19, VFIO forbids any SR-IOV VF management. > > There is a security concern about allowing userspace to manage SR-IOV > > VF messages and taking the responsibility for VFs in the guest. > > > > It is desired to allow the system admin deciding the security levels, > > by adding a flag in VFIO "let me manage VFs, I know what I am doing". > > Reference of "recent" discussion: https://lkml.org/lkml/2018/3/6/855 > > For now, there is no upstream solution merged. > > > > This patch is proposing a solution using an out-of-tree module. > > In this case, the admin will decide explicitly to bind the PF to vfio_pf. > > Unfortunately this solution won't work in environments which > > forbid any out-of-tree module. > > Another concern is that it looks like DPDK-only solution. > > > > We have an issue but we do not want to propose a half-solution > > which would harm other projects and users. > > So the question is: > > Do we accept this patch as a temporary solution? > > Or can we get an agreement soon for an upstream kernel solution? > > > > Thanks for reading and giving your (clear) opinion. Thanks, Alex for the feedback. > I'm pretty appalled that anyone would consider shipping this module and > actually claiming that it's supported in some way. Seriously, it's Actually DPDK already shipping with this hack using the igb_uio module for UIO. https://git.dpdk.org/dpdk/tree/kernel/linux/igb_uio/igb_uio.c#n44. > disturbing to see a driver that intentionally circumvents a security > issue that we all seem to agree exists, but just hand wave that it > doesn't apply to dpdk configurations. Yes. There is a security issue wrt netdev VFs. That's the reason, I was scared to submit any patch in upstream on this front. Having said that, OVS-DPDK kind of userland programs would like to define the fate of the netdev VF packets of the guest as it is vswitch application. So there is a perception change in who is controlling the who. > Ideas have been suggested > upstream for for quarantining VFs generated from user owned PFs such > that we require an opt-in to make use of them in this way. Nobody > seems to be pursuing such ideas upstream. I don't even see upstream > proposals to add a scary sounding module option to vfio-pci that would > taint the kernel, but make this available. If nothing else, please > remove the vfio name from this abomination, it has nothing to do with > vfio other than to try to subvert the security and isolation that vfio > attempts to provide. Thanks for the feedback. Let's hold on accepting this patch. We would like to have an upstream solution so that DPDK needs to only focus on userspace. I will work on submitting a patch for the discussion in Linux upstream. Let see how the discussion goes, Based on the that, We can revisit fate of this module. > Alex >