From: David Matlack <dmatlack@google.com>
To: Raghavendra Rao Ananta <rananta@google.com>
Cc: Alex Williamson <alex@shazbot.org>,
Alex Williamson <alex.williamson@redhat.com>,
Josh Hilke <jrhilke@google.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] vfio: selftests: Add tests to validate SR-IOV UAPI
Date: Thu, 6 Nov 2025 01:00:37 +0000 [thread overview]
Message-ID: <aQvzNZU9x9gmFzH3@google.com> (raw)
In-Reply-To: <20251104003536.3601931-5-rananta@google.com>
On 2025-11-04 12:35 AM, Raghavendra Rao Ananta wrote:
> +static const char *pf_dev_bdf;
> +static char vf_dev_bdf[16];
vf_dev_bdf can be part of the test fixture instead of a global variable.
pf_dev_bdf should be the only global variable since we have to get it
from main() into the text fixture.
> +
> +struct vfio_pci_device *pf_device;
> +struct vfio_pci_device *vf_device;
These can be local variables in the places they are used.
> +
> +static void test_vfio_pci_container_setup(struct vfio_pci_device *device,
> + const char *bdf,
> + const char *vf_token)
> +{
> + vfio_container_open(device);
> + vfio_pci_group_setup(device, bdf);
> + vfio_container_set_iommu(device);
> + __vfio_container_get_device_fd(device, bdf, vf_token);
> +}
> +
> +static int test_vfio_pci_iommufd_setup(struct vfio_pci_device *device,
> + const char *bdf, const char *vf_token)
> +{
> + vfio_pci_iommufd_cdev_open(device, bdf);
> + vfio_pci_iommufd_iommudev_open(device);
> + return __vfio_device_bind_iommufd(device->fd, device->iommufd, vf_token);
> +}
> +
> +static struct vfio_pci_device *test_vfio_pci_device_init(const char *bdf,
> + const char *iommu_mode,
> + const char *vf_token,
> + int *out_ret)
> +{
> + struct vfio_pci_device *device;
> +
> + device = calloc(1, sizeof(*device));
> + VFIO_ASSERT_NOT_NULL(device);
> +
> + device->iommu_mode = lookup_iommu_mode(iommu_mode);
> +
> + if (iommu_mode_container_path(iommu_mode)) {
> + test_vfio_pci_container_setup(device, bdf, vf_token);
> + /* The device fd will be -1 in case of mismatched tokens */
> + *out_ret = (device->fd < 0);
Maybe just return device->fd from test_vfio_pci_container_setup() so
this can be:
*out_ret = test_vfio_pci_container_setup(device, bdf, vf_token);
and then you can drop the curly braces.
> + } else {
> + *out_ret = test_vfio_pci_iommufd_setup(device, bdf, vf_token);
> + }
> +
> + return device;
> +}
> +
> +static void test_vfio_pci_device_cleanup(struct vfio_pci_device *device)
> +{
> + if (device->fd > 0)
> + VFIO_ASSERT_EQ(close(device->fd), 0);
> +
> + if (device->iommufd) {
> + VFIO_ASSERT_EQ(close(device->iommufd), 0);
> + } else {
> + VFIO_ASSERT_EQ(close(device->group_fd), 0);
> + VFIO_ASSERT_EQ(close(device->container_fd), 0);
> + }
> +
> + free(device);
> +}
> +
> +FIXTURE(vfio_pci_sriov_uapi_test) {};
> +
> +FIXTURE_SETUP(vfio_pci_sriov_uapi_test)
> +{
> + char vf_path[PATH_MAX] = {0};
> + char path[PATH_MAX] = {0};
> + unsigned int nr_vfs;
> + char buf[32] = {0};
> + int ret;
> + int fd;
> +
> + /* Check if SR-IOV is supported by the device */
> + snprintf(path, PATH_MAX, "%s/%s/sriov_totalvfs", PCI_SYSFS_PATH, pf_dev_bdf);
nit: Personally I would just hard-code the sysfs path instead of using
PCI_SYSFS_PATH. I think the code is more readable and more succinct that
way. And sysfs should be a stable ABI.
> + fd = open(path, O_RDONLY);
> + if (fd < 0) {
> + fprintf(stderr, "SR-IOV may not be supported by the device\n");
> + exit(KSFT_SKIP);
Use SKIP() for this:
if (fd < 0)
SKIP(return, "SR-IOV is not supported by the device\n");
Ditto below.
> + }
> +
> + ASSERT_GT(read(fd, buf, ARRAY_SIZE(buf)), 0);
> + ASSERT_EQ(close(fd), 0);
> + nr_vfs = strtoul(buf, NULL, 0);
> + if (nr_vfs < 0) {
> + fprintf(stderr, "SR-IOV may not be supported by the device\n");
> + exit(KSFT_SKIP);
> + }
> +
> + /* Setup VFs, if already not done */
Before creating VFs, should we disable auto-probing so the VFs don't get
bound to some other random driver (write 0 to sriov_drivers_autoprobe)?
> + snprintf(path, PATH_MAX, "%s/%s/sriov_numvfs", PCI_SYSFS_PATH, pf_dev_bdf);
> + ASSERT_GT(fd = open(path, O_RDWR), 0);
> + ASSERT_GT(read(fd, buf, ARRAY_SIZE(buf)), 0);
> + nr_vfs = strtoul(buf, NULL, 0);
> + if (nr_vfs == 0)
If VFs are already enabled, shouldn't the test fail or skip?
> + ASSERT_EQ(write(fd, "1", 1), 1);
> + ASSERT_EQ(close(fd), 0);
> +
> + /* Get the BDF of the first VF */
> + snprintf(path, PATH_MAX, "%s/%s/virtfn0", PCI_SYSFS_PATH, pf_dev_bdf);
> + ret = readlink(path, vf_path, PATH_MAX);
> + ASSERT_NE(ret, -1);
> + ret = sscanf(basename(vf_path), "%s", vf_dev_bdf);
> + ASSERT_EQ(ret, 1);
What ensures the created VF is bound to vfio-pci?
> +}
> +
> +FIXTURE_TEARDOWN(vfio_pci_sriov_uapi_test)
> +{
> +}
FIXTURE_TEARDOWN() should undo what FIXTURE_SETUP() did, i.e. write 0 to
sriov_numvfs. Otherwise running this test will leave behind SR-IOV
enabled on the PF.
You could also make this the users problem (the user has to provide a PF
with 1 VF where both PF and VF are bound to vfio-pci). But I think it
would be nice to make the test work automatically given a PF if we can.
next prev parent reply other threads:[~2025-11-06 1:00 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-04 0:35 [PATCH 0/4] vfio: selftest: Add SR-IOV UAPI test Raghavendra Rao Ananta
2025-11-04 0:35 ` [PATCH 1/4] vfio: selftests: Add support for passing vf_token in device init Raghavendra Rao Ananta
2025-11-05 23:52 ` David Matlack
2025-11-06 0:12 ` David Matlack
2025-11-06 16:33 ` Raghavendra Rao Ananta
2025-11-06 16:26 ` Raghavendra Rao Ananta
2025-11-06 17:17 ` David Matlack
2025-11-07 2:46 ` Raghavendra Rao Ananta
2025-11-06 0:14 ` David Matlack
2025-11-06 16:36 ` Raghavendra Rao Ananta
2025-11-06 17:10 ` David Matlack
2025-11-04 0:35 ` [PATCH 2/4] vfio: selftests: Export vfio_pci_device functions Raghavendra Rao Ananta
2025-11-06 0:41 ` David Matlack
2025-11-06 16:43 ` Raghavendra Rao Ananta
2025-11-06 17:08 ` David Matlack
2025-11-04 0:35 ` [PATCH 3/4] vfio: selftests: Add helper to set/override a vf_token Raghavendra Rao Ananta
2025-11-06 0:01 ` David Matlack
2025-11-06 16:44 ` Raghavendra Rao Ananta
2025-11-04 0:35 ` [PATCH 4/4] vfio: selftests: Add tests to validate SR-IOV UAPI Raghavendra Rao Ananta
2025-11-06 1:00 ` David Matlack [this message]
2025-11-06 17:05 ` Raghavendra Rao Ananta
2025-11-06 17:34 ` David Matlack
2025-11-07 2:56 ` Raghavendra Rao Ananta
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=aQvzNZU9x9gmFzH3@google.com \
--to=dmatlack@google.com \
--cc=alex.williamson@redhat.com \
--cc=alex@shazbot.org \
--cc=jrhilke@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rananta@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.