DPDK patches and discussions
 help / color / mirror / Atom feed
From: Vamsi Krishna Attunuru <vattunuru@marvell.com>
To: Alex Williamson <alex.williamson@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"mtosatti@redhat.com" <mtosatti@redhat.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>,
	"bluca@debian.org" <bluca@debian.org>,
	"jerinjacobk@gmail.com" <jerinjacobk@gmail.com>,
	"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
	"cohuck@redhat.com" <cohuck@redhat.com>
Subject: Re: [dpdk-dev] [PATCH v2 0/7] vfio/pci: SR-IOV support
Date: Thu, 5 Mar 2020 06:38:53 +0000	[thread overview]
Message-ID: <MWHPR18MB1645DCF80543381CF9115D09A6E20@MWHPR18MB1645.namprd18.prod.outlook.com> (raw)
In-Reply-To: <158213716959.17090.8399427017403507114.stgit@gimli.home>


> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Alex Williamson
> Sent: Thursday, February 20, 2020 12:24 AM
> To: kvm@vger.kernel.org
> Cc: linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org; dev@dpdk.org;
> mtosatti@redhat.com; thomas@monjalon.net; bluca@debian.org;
> jerinjacobk@gmail.com; bruce.richardson@intel.com; cohuck@redhat.com
> Subject: [dpdk-dev] [PATCH v2 0/7] vfio/pci: SR-IOV support
> 
> Changes since v1 are primarily to patch 3/7 where the commit log is
> rewritten, along with option parsing and failure logging based on upstream
> discussions.  The primary user visible difference is that option parsing is now
> much more strict.  If a vf_token option is provided that cannot be used, we
> generate an error.  As a result of this, opening a PF with a vf_token option
> will serve as a mechanism of setting the vf_token.  This seems like a more
> user friendly API than the alternative of sometimes requiring the option (VFs
> in use) and sometimes rejecting it, and upholds our desire that the option is
> always either used or rejected.
> 
> This also means that the VFIO_DEVICE_FEATURE ioctl is not the only means
> of setting the VF token, which might call into question whether we absolutely
> need this new ioctl.  Currently I'm keeping it because I can imagine use cases,
> for example if a hypervisor were to support SR-IOV, the PF device might be
> opened without consideration for a VF token and we'd require the
> hypservisor to close and re-open the PF in order to set a known VF token,
> which is impractical.
> 
> Series overview (same as provided with v1):
> 
> The synopsis of this series is that we have an ongoing desire to drive PCIe SR-
> IOV PFs from userspace with VFIO.  There's an immediate need for this with
> DPDK drivers and potentially interesting future use cases in virtualization.
> We've been reluctant to add this support previously due to the dependency
> and trust relationship between the VF device and PF driver.  Minimally the PF
> driver can induce a denial of service to the VF, but depending on the specific
> implementation, the PF driver might also be responsible for moving data
> between VFs or have direct access to the state of the VF, including data or
> state otherwise private to the VF or VF driver.
> 
> To help resolve these concerns, we introduce a VF token into the VFIO PCI
> ABI, which acts as a shared secret key between drivers.  The userspace PF
> driver is required to set the VF token to a known value and userspace VF
> drivers are required to provide the token to access the VF device.  If a PF
> driver is restarted with VF drivers in use, it must also provide the current
> token in order to prevent a rogue untrusted PF driver from replacing a known
> driver.  The degree to which this new token is considered secret is left to the
> userspace drivers, the kernel intentionally provides no means to retrieve the
> current token.
> 
> Note that the above token is only required for this new model where both
> the PF and VF devices are usable through vfio-pci.  Existing models of VFIO
> drivers where the PF is used without SR-IOV enabled or the VF is bound to a
> userspace driver with an in-kernel, host PF driver are unaffected.
> 
> The latter configuration above also highlights a new inverted scenario that is
> now possible, a userspace PF driver with in-kernel VF drivers.
> I believe this is a scenario that should be allowed, but should not be enabled
> by default.  This series includes code to set a default driver_override for VFs
> sourced from a vfio-pci user owned PF, such that the VFs are also bound to
> vfio-pci.  This model is compatible with tools like driverctl and allows the
> system administrator to decide if other bindings should be enabled.  The VF
> token interface above exists only between vfio-pci PF and VF drivers, once a
> VF is bound to another driver, the administrator has effectively pronounced
> the device as trusted.  The vfio-pci driver will note alternate binding in dmesg
> for logging and debugging purposes.
> 
> Please review, comment, and test.  The example QEMU implementation
> provided with the RFC is still current for this version.  Thanks,
> 
> Alex

Hi Alex,

Thanks for enabling this feature support.

Tested-by: Vamsi Attunuru <vattunuru@marvell.com>

Tested v2 patch set with below DPDK patch.
http://patches.dpdk.org/patch/66281/

Regards
A Vamsi

> 
> RFC: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lore.kernel.org_lkml_158085337582.9445.17682266437583505502.stgit-
> 40gimli.home_&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=2rpxxNF2qeP0
> 2gVZIWTVrW-6zNZz5-uKt9pRqpR_M3U&m=V-6mKmCTHPZa5jwepXU_-
> Ma1_BGF0OWJ_IRCF_p4GVo&s=YnO98PGK9ro7F6_XZTccHdYcZ-
> rMMOin0nRFhPD6Uv4&e=
> v1: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lore.kernel.org_lkml_158145472604.16827.15751375540102298130.stgit
> -
> 40gimli.home_&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=2rpxxNF2qeP0
> 2gVZIWTVrW-6zNZz5-uKt9pRqpR_M3U&m=V-6mKmCTHPZa5jwepXU_-
> Ma1_BGF0OWJ_IRCF_p4GVo&s=rvUxLCENwNk0GBYkcsBVVobsLfMb4BV5gtc
> 3VqYQTS4&e=
> 
> ---
> 
> Alex Williamson (7):
>       vfio: Include optional device match in vfio_device_ops callbacks
>       vfio/pci: Implement match ops
>       vfio/pci: Introduce VF token
>       vfio: Introduce VFIO_DEVICE_FEATURE ioctl and first user
>       vfio/pci: Add sriov_configure support
>       vfio/pci: Remove dev_fmt definition
>       vfio/pci: Cleanup .probe() exit paths
> 
> 
>  drivers/vfio/pci/vfio_pci.c         |  383
> +++++++++++++++++++++++++++++++++--
>  drivers/vfio/pci/vfio_pci_private.h |   10 +
>  drivers/vfio/vfio.c                 |   20 +-
>  include/linux/vfio.h                |    4
>  include/uapi/linux/vfio.h           |   37 +++
>  5 files changed, 426 insertions(+), 28 deletions(-)


      parent reply	other threads:[~2020-03-05  6:39 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19 18:53 Alex Williamson
2020-02-19 18:53 ` [dpdk-dev] [PATCH v2 1/7] vfio: Include optional device match in vfio_device_ops callbacks Alex Williamson
2020-02-19 18:54 ` [dpdk-dev] [PATCH v2 2/7] vfio/pci: Implement match ops Alex Williamson
2020-02-19 18:54 ` [dpdk-dev] [PATCH v2 3/7] vfio/pci: Introduce VF token Alex Williamson
2020-02-25  2:59   ` Tian, Kevin
2020-03-05 18:17     ` Alex Williamson
2020-03-06  8:32       ` Tian, Kevin
2020-03-06 15:39         ` Alex Williamson
2020-03-07  1:04           ` Tian, Kevin
2020-03-09  0:46             ` Alex Williamson
2020-03-09  1:22               ` Tian, Kevin
2020-03-09  1:33               ` Tian, Kevin
2020-03-09 15:35                 ` Alex Williamson
2020-02-19 18:54 ` [dpdk-dev] [PATCH v2 4/7] vfio: Introduce VFIO_DEVICE_FEATURE ioctl and first user Alex Williamson
2020-02-27 17:34   ` Cornelia Huck
2020-03-05 20:51     ` Alex Williamson
2020-02-19 18:54 ` [dpdk-dev] [PATCH v2 5/7] vfio/pci: Add sriov_configure support Alex Williamson
2020-02-25  3:08   ` Tian, Kevin
2020-03-05 18:22     ` Alex Williamson
2020-03-05 20:08       ` Ajit Khaparde
2020-03-06  7:57       ` Tian, Kevin
2020-03-06 22:17         ` Alex Williamson
2020-03-07  1:35           ` Tian, Kevin
2020-03-09  0:46             ` Alex Williamson
2020-03-09  1:48               ` Tian, Kevin
2020-03-09 14:56                 ` Alex Williamson
2020-03-06  9:45       ` Tian, Kevin
2020-03-06 15:50         ` Alex Williamson
2020-02-19 18:54 ` [dpdk-dev] [PATCH v2 6/7] vfio/pci: Remove dev_fmt definition Alex Williamson
2020-02-19 18:54 ` [dpdk-dev] [PATCH v2 7/7] vfio/pci: Cleanup .probe() exit paths Alex Williamson
2020-02-25  2:33 ` [dpdk-dev] [PATCH v2 0/7] vfio/pci: SR-IOV support Tian, Kevin
2020-02-25  6:09   ` Jason Wang
2020-03-05 17:14     ` Alex Williamson
2020-03-06  3:35       ` Jason Wang
2020-03-06 16:24         ` Alex Williamson
2020-03-09  3:36           ` Jason Wang
2020-03-09 14:45             ` Alex Williamson
2020-03-05 17:33   ` Alex Williamson
2020-03-06  9:21     ` Tian, Kevin
2020-03-05  6:38 ` Vamsi Krishna Attunuru [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MWHPR18MB1645DCF80543381CF9115D09A6E20@MWHPR18MB1645.namprd18.prod.outlook.com \
    --to=vattunuru@marvell.com \
    --cc=alex.williamson@redhat.com \
    --cc=bluca@debian.org \
    --cc=bruce.richardson@intel.com \
    --cc=cohuck@redhat.com \
    --cc=dev@dpdk.org \
    --cc=jerinjacobk@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).