DPDK patches and discussions
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: kvm@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, dpdk-dev <dev@dpdk.org>,
	mtosatti@redhat.com, Thomas Monjalon <thomas@monjalon.net>,
	Luca Boccassi <bluca@debian.org>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	cohuck@redhat.com, Vamsi Attunuru <vattunuru@marvell.com>
Subject: Re: [dpdk-dev] [RFC PATCH 0/7] vfio/pci: SR-IOV support
Date: Tue, 11 Feb 2020 10:06:12 -0700	[thread overview]
Message-ID: <20200211100612.65cf2433@w520.home> (raw)
In-Reply-To: <CALBAE1Oz2u+cmoL8LhEZ-4paXEebKh3DzfWGLQLQx0oaW=tBXw@mail.gmail.com>

On Tue, 11 Feb 2020 16:48:47 +0530
Jerin Jacob <jerinjacobk@gmail.com> wrote:

> On Wed, Feb 5, 2020 at 4:35 AM Alex Williamson
> <alex.williamson@redhat.com> wrote:
> >
> > There seems to be an ongoing desire to use userspace, vfio-based
> > drivers for both SR-IOV PF and VF devices.  The fundamental issue
> > with this concept is that the VF is not fully independent of the PF
> > driver.  Minimally the PF driver might be able to deny service to the
> > VF, VF data paths might be dependent on the state of the PF device,
> > or the PF my have some degree of ability to inspect or manipulate the
> > VF data.  It therefore would seem irresponsible to unleash VFs onto
> > the system, managed by a user owned PF.
> >
> > We address this in a few ways in this series.  First, we can use a bus
> > notifier and the driver_override facility to make sure VFs are bound
> > to the vfio-pci driver by default.  This should eliminate the chance
> > that a VF is accidentally bound and used by host drivers.  We don't
> > however remove the ability for a host admin to change this override.
> >
> > The next issue we need to address is how we let userspace drivers
> > opt-in to this participation with the PF driver.  We do not want an
> > admin to be able to unwittingly assign one of these VFs to a tenant
> > that isn't working in collaboration with the PF driver.  We could use
> > IOMMU grouping, but this seems to push too far towards tightly coupled
> > PF and VF drivers.  This series introduces a "VF token", implemented
> > as a UUID, as a shared secret between PF and VF drivers.  The token
> > needs to be set by the PF driver and used as part of the device
> > matching by the VF driver.  Provisions in the code also account for
> > restarting the PF driver with active VF drivers, requiring the PF to
> > use the current token to re-gain access to the PF.  
> 
> Thanks Alex for the series. DPDK realizes this use-case through, an out of
> tree igb_uio module, for non VFIO devices. Supporting this use case, with
> VFIO, will be a great enhancement for DPDK as we are planning to
> get rid of out of tree modules any focus only on userspace aspects.
> 
> From the DPDK perspective, we have following use-cases
> 
> 1) VF representer or OVS/vSwitch  use cases where
> DPDK PF acts as an HW switch to steer traffic to VF
> using the rte_flow library backed by HW CAMs.
> 
> 2) Unlike, other PCI class of devices, Network class of PCIe devices
> would have additional
> capability on the PF devices such as promiscuous mode support etc
> leverage that in DPDK
> PF and VF use cases.
> 
> That would boil down to the use of the following topology.
> a)  PF bound to DPDK/VFIO  and  VF bound to Linux
> b)  PF bound to DPDK/VFIO  and  VF bound to DPDK/VFIO
> 
> Tested the use case (a) and it works this patch. Tested use case(b), it
> works with patch provided both PF and VF under the same application.
> 
> Regarding the use case where  PF bound to DPDK/VFIO and
> VF bound to DPDK/VFIO are _two different_ processes then sharing the UUID
> will be a little tricky thing in terms of usage. But if that is the
> purpose of bringing
> UUID to the equation then it fine.
> 
> Overall this series looks good to me.  We can test the next non-RFC
> series and give
> Tested-by by after testing with DPDK.

Thanks Jerin, that's great feedback.  For case b), it is rather the
intention of the shared VF token proposed here that it imposes some
small barrier in validating the collaboration between the PF and VF
drivers.  In a trusted environment, a common UUID might be exposed in a
shared file and the same token could be used by all PFs and VFs on the
system, or datacenter.  The goal is simply to make sure the
collaboration is explicit, I don't want to be fielding support issues
from users assigning PFs and VFs to unrelated VM instances or
unintentionally creating your scenario a) configuration.

With the positive response from you and Thomas, I'll post a non-RFC
version and barring any blockers maybe we can get this in for the v5.7
kernel.  Thanks,

Alex


  parent reply	other threads:[~2020-02-11 17:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-04 23:05 Alex Williamson
2020-02-04 23:05 ` [dpdk-dev] [RFC PATCH 1/7] vfio: Include optional device match in vfio_device_ops callbacks Alex Williamson
2020-02-06 11:14   ` Cornelia Huck
2020-02-06 18:18     ` Alex Williamson
2020-02-07  9:33       ` Cornelia Huck
2020-02-04 23:05 ` [dpdk-dev] [RFC PATCH 2/7] vfio/pci: Implement match ops Alex Williamson
2020-02-04 23:06 ` [dpdk-dev] [RFC PATCH 3/7] vfio/pci: Introduce VF token Alex Williamson
2020-02-05  7:57   ` Liu, Yi L
2020-02-05 14:13     ` Alex Williamson
2020-02-04 23:06 ` [dpdk-dev] [RFC PATCH 4/7] vfio: Introduce VFIO_DEVICE_FEATURE ioctl and first user Alex Williamson
2020-02-04 23:06 ` [dpdk-dev] [RFC PATCH 5/7] vfio/pci: Add sriov_configure support Alex Williamson
2020-02-04 23:06 ` [dpdk-dev] [RFC PATCH 6/7] vfio/pci: Remove dev_fmt definition Alex Williamson
2020-02-06 13:45   ` Cornelia Huck
2020-02-04 23:06 ` [dpdk-dev] [RFC PATCH 7/7] vfio/pci: Cleanup .probe() exit paths Alex Williamson
2020-02-04 23:17 ` [dpdk-dev] [RFC PATCH 0/7] vfio/pci: SR-IOV support Alex Williamson
2020-02-05  7:57   ` Liu, Yi L
2020-02-05 14:18     ` Alex Williamson
2020-02-05  7:01 ` Christoph Hellwig
2020-02-05 13:58   ` Alex Williamson
2020-02-05  7:57 ` Liu, Yi L
2020-02-05 14:10   ` Alex Williamson
2020-02-11 11:18 ` Jerin Jacob
2020-02-11 13:57   ` Thomas Monjalon
2020-02-11 17:06   ` Alex Williamson [this message]
2020-02-11 18:03     ` Jerin Jacob

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=20200211100612.65cf2433@w520.home \
    --to=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 \
    --cc=vattunuru@marvell.com \
    /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).