From: Alex Williamson <alex.williamson@redhat.com>
To: "Liu, Yi L" <yi.l.liu@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"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>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"cohuck@redhat.com" <cohuck@redhat.com>
Subject: Re: [dpdk-dev] [RFC PATCH 0/7] vfio/pci: SR-IOV support
Date: Wed, 5 Feb 2020 07:18:26 -0700 [thread overview]
Message-ID: <20200205071826.6d4d43d7@x1.home> (raw)
In-Reply-To: <A2975661238FB949B60364EF0F2C25743A1ABFF9@SHSMSX104.ccr.corp.intel.com>
On Wed, 5 Feb 2020 07:57:36 +0000
"Liu, Yi L" <yi.l.liu@intel.com> wrote:
> > From: Alex Williamson <alex.williamson@redhat.com>
> > Sent: Wednesday, February 5, 2020 7:18 AM
> > To: kvm@vger.kernel.org
> > Subject: Re: [RFC PATCH 0/7] vfio/pci: SR-IOV support
> >
> >
> > Promised example QEMU test case...
> >
> > commit 3557c63bcb286c71f3f7242cad632edd9e297d26
> > Author: Alex Williamson <alex.williamson@redhat.com>
> > Date: Tue Feb 4 13:47:41 2020 -0700
> >
> > vfio-pci: QEMU support for vfio-pci VF tokens
> >
> > Example support for using a vf_token to gain access to a device as
> > well as using the VFIO_DEVICE_FEATURE interface to set the VF token.
> > Note that the kernel will disregard the additional option where it's
> > not required, such as opening the PF with no VF users, so we can
> > always provide it.
> >
> > NB. It's unclear whether there's value to this QEMU support without
> > further exposure of SR-IOV within a VM. This is meant mostly as a
> > test case where the real initial users will likely be DPDK drivers.
> >
> > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
>
> Just curious how UUID is used across the test. Should the QEMU
> which opens VFs add the vfio_token=UUID or the QEMU which
> opens PF add the vfio_token=UUID? or both should add vfio_token=UUID.
In this example we do both as this covers the case where there are
existing VF users, which requires the PF to also provide the vf_token.
If there are no VF users, the PF is not required to provide a vf_token
and vfio-pci will not fail the device match if a vf_token is provided
but not needed. In fact, when a PF is probed by vfio-pci a random
vf_token is set, so it's required to use a PF driver to set a known
vf_token before any VF users can access their VFs. Thanks,
Alex
next prev parent reply other threads:[~2020-02-05 14:18 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 [this message]
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
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=20200205071826.6d4d43d7@x1.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=yi.l.liu@intel.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).