Cover Detail
Show a cover letter.
GET /api/covers/65915/?format=api
{ "id": 65915, "url": "http://patches.dpdk.org/api/covers/65915/?format=api", "web_url": "http://patches.dpdk.org/project/dpdk/cover/158213716959.17090.8399427017403507114.stgit@gimli.home/", "project": { "id": 1, "url": "http://patches.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": "<158213716959.17090.8399427017403507114.stgit@gimli.home>", "list_archive_url": "https://inbox.dpdk.org/dev/158213716959.17090.8399427017403507114.stgit@gimli.home", "date": "2020-02-19T18:53:46", "name": "[v2,0/7] vfio/pci: SR-IOV support", "submitter": { "id": 391, "url": "http://patches.dpdk.org/api/people/391/?format=api", "name": "Alex Williamson", "email": "alex.williamson@redhat.com" }, "mbox": "http://patches.dpdk.org/project/dpdk/cover/158213716959.17090.8399427017403507114.stgit@gimli.home/mbox/", "series": [ { "id": 8618, "url": "http://patches.dpdk.org/api/series/8618/?format=api", "web_url": "http://patches.dpdk.org/project/dpdk/list/?series=8618", "date": "2020-02-19T18:53:46", "name": "vfio/pci: SR-IOV support", "version": 2, "mbox": "http://patches.dpdk.org/series/8618/mbox/" } ], "comments": "http://patches.dpdk.org/api/covers/65915/comments/", "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 BBE74A0555;\n\tWed, 19 Feb 2020 19:54:03 +0100 (CET)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 8E3EF1B951;\n\tWed, 19 Feb 2020 19:54:02 +0100 (CET)", "from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com\n [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id 712271B13C\n for <dev@dpdk.org>; Wed, 19 Feb 2020 19:54:00 +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-56-JYUDF0GWNu6vXN8CwF6baQ-1; Wed, 19 Feb 2020 13:53:51 -0500", "from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com\n [10.5.11.16])\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 1F401107ACC5;\n Wed, 19 Feb 2020 18:53:50 +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 80B505C1B0;\n Wed, 19 Feb 2020 18:53:46 +0000 (UTC)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1582138439;\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=ooAVZmPqmpejcE1lho8HJzD9Jr6TIc1QTP2vQodr9hU=;\n b=f0K7xq+LeM606qSil19DG9S5dj/1amqAZ4qg7UOgu7YLpKSztO8jfCDBu5569uQ2i2VVk4\n Bb2WGPKOJkxeiroy2KATa2jeU3A7eNkX1BzbXSunzxvRv5LmRZQ3YvwZp84d7kHtcuYJSy\n t+Llpt5awRO9xbZ6JJORJFbRml7i70I=", "X-MC-Unique": "JYUDF0GWNu6vXN8CwF6baQ-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": "Wed, 19 Feb 2020 11:53:46 -0700", "Message-ID": "<158213716959.17090.8399427017403507114.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.79 on 10.5.11.16", "Subject": "[dpdk-dev] [PATCH v2 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": "Changes since v1 are primarily to patch 3/7 where the commit log is\nrewritten, along with option parsing and failure logging based on\nupstream discussions. The primary user visible difference is that\noption parsing is now much more strict. If a vf_token option is\nprovided that cannot be used, we generate an error. As a result of\nthis, opening a PF with a vf_token option will serve as a mechanism of\nsetting the vf_token. This seems like a more user friendly API than\nthe alternative of sometimes requiring the option (VFs in use) and\nsometimes rejecting it, and upholds our desire that the option is\nalways either used or rejected.\n\nThis also means that the VFIO_DEVICE_FEATURE ioctl is not the only\nmeans of setting the VF token, which might call into question whether\nwe absolutely need this new ioctl. Currently I'm keeping it because I\ncan imagine use cases, for example if a hypervisor were to support\nSR-IOV, the PF device might be opened without consideration for a VF\ntoken and we'd require the hypservisor to close and re-open the PF in\norder to set a known VF token, which is impractical.\n\nSeries overview (same as provided with v1):\n\nThe synopsis of this series is that we have an ongoing desire to drive\nPCIe SR-IOV PFs from userspace with VFIO. There's an immediate need\nfor this with DPDK drivers and potentially interesting future use\ncases in virtualization. We've been reluctant to add this support\npreviously due to the dependency and trust relationship between the\nVF device and PF driver. Minimally the PF driver can induce a denial\nof service to the VF, but depending on the specific implementation,\nthe PF driver might also be responsible for moving data between VFs\nor have direct access to the state of the VF, including data or state\notherwise private to the VF or VF driver.\n\nTo help resolve these concerns, we introduce a VF token into the VFIO\nPCI ABI, which acts as a shared secret key between drivers. The\nuserspace PF driver is required to set the VF token to a known value\nand userspace VF drivers are required to provide the token to access\nthe VF device. If a PF driver is restarted with VF drivers in use, it\nmust also provide the current token in order to prevent a rogue\nuntrusted PF driver from replacing a known driver. The degree to\nwhich this new token is considered secret is left to the userspace\ndrivers, the kernel intentionally provides no means to retrieve the\ncurrent token.\n\nNote that the above token is only required for this new model where\nboth the PF and VF devices are usable through vfio-pci. Existing\nmodels of VFIO drivers where the PF is used without SR-IOV enabled\nor the VF is bound to a userspace driver with an in-kernel, host PF\ndriver are unaffected.\n\nThe latter configuration above also highlights a new inverted scenario\nthat is now possible, a userspace PF driver with in-kernel VF drivers.\nI believe this is a scenario that should be allowed, but should not be\nenabled by default. This series includes code to set a default\ndriver_override for VFs sourced from a vfio-pci user owned PF, such\nthat the VFs are also bound to vfio-pci. This model is compatible\nwith tools like driverctl and allows the system administrator to\ndecide if other bindings should be enabled. The VF token interface\nabove exists only between vfio-pci PF and VF drivers, once a VF is\nbound to another driver, the administrator has effectively pronounced\nthe device as trusted. The vfio-pci driver will note alternate\nbinding in dmesg for logging and debugging purposes.\n\nPlease review, comment, and test. The example QEMU implementation\nprovided with the RFC is still current for this version. Thanks,\n\nAlex\n\nRFC: https://lore.kernel.org/lkml/158085337582.9445.17682266437583505502.stgit@gimli.home/\nv1: https://lore.kernel.org/lkml/158145472604.16827.15751375540102298130.stgit@gimli.home/\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 | 383 +++++++++++++++++++++++++++++++++--\n drivers/vfio/pci/vfio_pci_private.h | 10 +\n drivers/vfio/vfio.c | 20 +-\n include/linux/vfio.h | 4 \n include/uapi/linux/vfio.h | 37 +++\n 5 files changed, 426 insertions(+), 28 deletions(-)" }