Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/65565/?format=api
{ "id": 65565, "url": "http://patchwork.dpdk.org/api/patches/65565/?format=api", "web_url": "http://patchwork.dpdk.org/project/dpdk/patch/158085337582.9445.17682266437583505502.stgit@gimli.home/", "project": { "id": 1, "url": "http://patchwork.dpdk.org/api/projects/1/?format=api", "name": "DPDK", "link_name": "dpdk", "list_id": "dev.dpdk.org", "list_email": "dev@dpdk.org", "web_url": "http://core.dpdk.org", "scm_url": "git://dpdk.org/dpdk", "webscm_url": "http://git.dpdk.org/dpdk", "list_archive_url": "https://inbox.dpdk.org/dev", "list_archive_url_format": "https://inbox.dpdk.org/dev/{}", "commit_url_format": "" }, "msgid": "<158085337582.9445.17682266437583505502.stgit@gimli.home>", "list_archive_url": "https://inbox.dpdk.org/dev/158085337582.9445.17682266437583505502.stgit@gimli.home", "date": "2020-02-04T23:05:34", "name": "[RFC,0/7] vfio/pci: SR-IOV support", "commit_ref": null, "pull_url": null, "state": null, "archived": false, "hash": null, "submitter": { "id": 391, "url": "http://patchwork.dpdk.org/api/people/391/?format=api", "name": "Alex Williamson", "email": "alex.williamson@redhat.com" }, "delegate": null, "mbox": "http://patchwork.dpdk.org/project/dpdk/patch/158085337582.9445.17682266437583505502.stgit@gimli.home/mbox/", "series": [], "comments": "http://patchwork.dpdk.org/api/patches/65565/comments/", "check": "pending", "checks": "http://patchwork.dpdk.org/api/patches/65565/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 61C7FA0533;\n\tWed, 5 Feb 2020 00:05:46 +0100 (CET)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id B2BB51C10D;\n\tWed, 5 Feb 2020 00:05:45 +0100 (CET)", "from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com\n [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id A9C151C0DC\n for <dev@dpdk.org>; Wed, 5 Feb 2020 00:05:44 +0100 (CET)", "from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com\n [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id\n us-mta-63-_PGm0uoKPEO2dpkXo_Cobw-1; Tue, 04 Feb 2020 18:05:39 -0500", "from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com\n [10.5.11.22])\n (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n (No client certificate requested)\n by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E1C5F1085926;\n Tue, 4 Feb 2020 23:05:37 +0000 (UTC)", "from gimli.home (ovpn-116-28.phx2.redhat.com [10.3.116.28])\n by smtp.corp.redhat.com (Postfix) with ESMTP id 88DEA1084194;\n Tue, 4 Feb 2020 23:05:34 +0000 (UTC)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1580857543;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding;\n bh=50yJ/0uSQd8YRp4Nzpt7nFwJU44bA7UT36hqDKQZmJc=;\n b=TZxM/3haiTtCkhp6j1IFQXCq254ZD8+17Vsj0txbfa0Rse90I1MUHaVokzKc8qWbqX6tjJ\n 2LSR9gYDHh7zRFCSP+1dnXykAvIzT+KJpGMy3UXRCKIsjjrByuIEl9dQ6SL3mL96Vt9Chq\n MhpByx/UZ4yQ+EoIzD9jk2ZZH+gSKa8=", "X-MC-Unique": "_PGm0uoKPEO2dpkXo_Cobw-1", "From": "Alex Williamson <alex.williamson@redhat.com>", "To": "kvm@vger.kernel.org", "Cc": "linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, dev@dpdk.org,\n mtosatti@redhat.com, thomas@monjalon.net, bluca@debian.org,\n jerinjacobk@gmail.com, bruce.richardson@intel.com, cohuck@redhat.com", "Date": "Tue, 04 Feb 2020 16:05:34 -0700", "Message-ID": "<158085337582.9445.17682266437583505502.stgit@gimli.home>", "User-Agent": "StGit/0.19-dirty", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=\"utf-8\"", "Content-Transfer-Encoding": "7bit", "X-Scanned-By": "MIMEDefang 2.84 on 10.5.11.22", "Subject": "[dpdk-dev] [RFC PATCH 0/7] vfio/pci: SR-IOV support", "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>,\n <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>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "content": "There seems to be an ongoing desire to use userspace, vfio-based\ndrivers for both SR-IOV PF and VF devices. The fundamental issue\nwith this concept is that the VF is not fully independent of the PF\ndriver. Minimally the PF driver might be able to deny service to the\nVF, VF data paths might be dependent on the state of the PF device,\nor the PF my have some degree of ability to inspect or manipulate the\nVF data. It therefore would seem irresponsible to unleash VFs onto\nthe system, managed by a user owned PF.\n\nWe address this in a few ways in this series. First, we can use a bus\nnotifier and the driver_override facility to make sure VFs are bound\nto the vfio-pci driver by default. This should eliminate the chance\nthat a VF is accidentally bound and used by host drivers. We don't\nhowever remove the ability for a host admin to change this override.\n\nThe next issue we need to address is how we let userspace drivers\nopt-in to this participation with the PF driver. We do not want an\nadmin to be able to unwittingly assign one of these VFs to a tenant\nthat isn't working in collaboration with the PF driver. We could use\nIOMMU grouping, but this seems to push too far towards tightly coupled\nPF and VF drivers. This series introduces a \"VF token\", implemented\nas a UUID, as a shared secret between PF and VF drivers. The token\nneeds to be set by the PF driver and used as part of the device\nmatching by the VF driver. Provisions in the code also account for\nrestarting the PF driver with active VF drivers, requiring the PF to\nuse the current token to re-gain access to the PF.\n\nThe above solutions introduce a bit of a modification to the VFIO ABI\nand an additional ABI extension. The modification is that the\nVFIO_GROUP_GET_DEVICE_FD ioctl is specified to require a char string\nfrom the user providing the device name. For this solution, we extend\nthe syntax to allow the device name followed by key/value pairs. In\nthis case we add \"vf_token=3e7e882e-1daf-417f-ad8d-882eea5ee337\", for\nexample. These options are expected to be space separated. Matching\nthese key/value pairs is entirely left to the vfio bus driver (ex.\nvfio-pci) and the internal ops structure is extended to allow this\noptional support. This extension should be fully backwards compatible\nto existing userspace, such code will simply fail to open these newly\nexposed devices, as intended.\n\nI've been debating whether instead of the above we should allow the\nuser to get the device fd as normal, but restrict the interfaces until\nthe user authenticates, but I'm afraid this would be a less backwards\ncompatible solution. It would be just as unclear to the user why a\ndevice read/write/mmap/ioctl failed as it might be to why getting the\ndevice fd could fail. However in the latter case, I believe we do a\nbetter job of restricting how far userspace code might go before they\nultimately fail. I'd welcome discussion in the space, and or course\nthe extension of the GET_DEVICE_FD string.\n\nFinally, the user needs to be able to set a VF token. I add a\nVFIO_DEVICE_FEATURE ioctl for this that's meant to be reusable for\ngetting, setting, and probing arbitrary features of a device.\n\nI'll reply to this cover letter with a very basic example of a QEMU\nupdate to support this interface, though I haven't found a device yet\nthat behaves well with the PF running in one VM with the VF in\nanother, or really even just a PF running in a VM with SR-IOV enabled.\nI know these devices exist though, and I suspect QEMU will not be the\nprimary user of this support for now, but this behavior reaffirms my\nconcerns to prevent mis-use.\n\nPlease comment. In particular, does this approach meet the DPDK needs\nfor userspace PF and VF drivers, with the hopefully minor hurdle of\nsharing a token between drivers. The token is of course left to\nuserspace how to manage, and might be static (and not very secret) for\na given set of drivers. Thanks,\n\nAlex\n\n---\n\nAlex Williamson (7):\n vfio: Include optional device match in vfio_device_ops callbacks\n vfio/pci: Implement match ops\n vfio/pci: Introduce VF token\n vfio: Introduce VFIO_DEVICE_FEATURE ioctl and first user\n vfio/pci: Add sriov_configure support\n vfio/pci: Remove dev_fmt definition\n vfio/pci: Cleanup .probe() exit paths\n\n\n drivers/vfio/pci/vfio_pci.c | 315 ++++++++++++++++++++++++++++++++---\n drivers/vfio/pci/vfio_pci_private.h | 10 +\n drivers/vfio/vfio.c | 19 ++\n include/linux/vfio.h | 3 \n include/uapi/linux/vfio.h | 37 ++++\n 5 files changed, 356 insertions(+), 28 deletions(-)", "diff": null, "prefixes": [ "RFC", "0/7" ] }