From: Eric Auger <eric.auger@redhat.com>
To: Yi Liu <yi.l.liu@intel.com>,
alex.williamson@redhat.com, jgg@nvidia.com, kevin.tian@intel.com
Cc: linux-s390@vger.kernel.org, yi.y.sun@linux.intel.com,
kvm@vger.kernel.org, mjrosato@linux.ibm.com,
intel-gvt-dev@lists.freedesktop.org, joro@8bytes.org,
cohuck@redhat.com, xudong.hao@intel.com, peterx@redhat.com,
yan.y.zhao@intel.com, terrence.xu@intel.com, nicolinc@nvidia.com,
shameerali.kolothum.thodi@huawei.com,
suravee.suthikulpanit@amd.com, intel-gfx@lists.freedesktop.org,
chao.p.peng@linux.intel.com, lulu@redhat.com,
robin.murphy@arm.com, jasowang@redhat.com,
yanting.jiang@intel.com
Subject: Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
Date: Wed, 5 Apr 2023 14:19:32 +0200 [thread overview]
Message-ID: <a937e622-ce32-6dda-d77c-7d8d76474ee0@redhat.com> (raw)
In-Reply-To: <20230401144429.88673-13-yi.l.liu@intel.com>
Hi Yi,
On 4/1/23 16:44, Yi Liu wrote:
> for the users that accept device fds passed from management stacks to be
> able to figure out the host reset affected devices among the devices
> opened by the user. This is needed as such users do not have BDF (bus,
> devfn) knowledge about the devices it has opened, hence unable to use
> the information reported by existing VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
> to figure out the affected devices.
>
> Signed-off-by: Yi Liu <yi.l.liu@intel.com>
> ---
> drivers/vfio/pci/vfio_pci_core.c | 58 ++++++++++++++++++++++++++++----
> include/uapi/linux/vfio.h | 24 ++++++++++++-
> 2 files changed, 74 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> index 19f5b075d70a..a5a7e148dce1 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -30,6 +30,7 @@
> #if IS_ENABLED(CONFIG_EEH)
> #include <asm/eeh.h>
> #endif
> +#include <uapi/linux/iommufd.h>
>
> #include "vfio_pci_priv.h"
>
> @@ -767,6 +768,20 @@ static int vfio_pci_get_irq_count(struct vfio_pci_core_device *vdev, int irq_typ
> return 0;
> }
>
> +static struct vfio_device *
> +vfio_pci_find_device_in_devset(struct vfio_device_set *dev_set,
> + struct pci_dev *pdev)
> +{
> + struct vfio_device *cur;
> +
> + lockdep_assert_held(&dev_set->lock);
> +
> + list_for_each_entry(cur, &dev_set->device_list, dev_set_list)
> + if (cur->dev == &pdev->dev)
> + return cur;
> + return NULL;
> +}
> +
> static int vfio_pci_count_devs(struct pci_dev *pdev, void *data)
> {
> (*(int *)data)++;
> @@ -776,13 +791,20 @@ static int vfio_pci_count_devs(struct pci_dev *pdev, void *data)
> struct vfio_pci_fill_info {
> int max;
> int cur;
> + bool require_devid;
> + struct iommufd_ctx *iommufd;
> + struct vfio_device_set *dev_set;
> struct vfio_pci_dependent_device *devices;
> };
>
> static int vfio_pci_fill_devs(struct pci_dev *pdev, void *data)
> {
> struct vfio_pci_fill_info *fill = data;
> + struct vfio_device_set *dev_set = fill->dev_set;
> struct iommu_group *iommu_group;
> + struct vfio_device *vdev;
> +
> + lockdep_assert_held(&dev_set->lock);
>
> if (fill->cur == fill->max)
> return -EAGAIN; /* Something changed, try again */
> @@ -791,7 +813,21 @@ static int vfio_pci_fill_devs(struct pci_dev *pdev, void *data)
> if (!iommu_group)
> return -EPERM; /* Cannot reset non-isolated devices */
>
> - fill->devices[fill->cur].group_id = iommu_group_id(iommu_group);
> + if (fill->require_devid) {
> + /*
> + * Report dev_id of the devices that are opened as cdev
> + * and have the same iommufd with the fill->iommufd.
> + * Otherwise, just fill IOMMUFD_INVALID_ID.
> + */
> + vdev = vfio_pci_find_device_in_devset(dev_set, pdev);
> + if (vdev && vfio_device_cdev_opened(vdev) &&
> + fill->iommufd == vfio_iommufd_physical_ictx(vdev))
> + vfio_iommufd_physical_devid(vdev, &fill->devices[fill->cur].dev_id);
> + else
> + fill->devices[fill->cur].dev_id = IOMMUFD_INVALID_ID;
> + } else {
> + fill->devices[fill->cur].group_id = iommu_group_id(iommu_group);
> + }
> fill->devices[fill->cur].segment = pci_domain_nr(pdev->bus);
> fill->devices[fill->cur].bus = pdev->bus->number;
> fill->devices[fill->cur].devfn = pdev->devfn;
> @@ -1230,17 +1266,27 @@ static int vfio_pci_ioctl_get_pci_hot_reset_info(
> return -ENOMEM;
>
> fill.devices = devices;
> + fill.dev_set = vdev->vdev.dev_set;
>
> + mutex_lock(&vdev->vdev.dev_set->lock);
> + if (vfio_device_cdev_opened(&vdev->vdev)) {
> + fill.require_devid = true;
> + fill.iommufd = vfio_iommufd_physical_ictx(&vdev->vdev);
> + }
> ret = vfio_pci_for_each_slot_or_bus(vdev->pdev, vfio_pci_fill_devs,
> &fill, slot);
> + mutex_unlock(&vdev->vdev.dev_set->lock);
>
> /*
> * If a device was removed between counting and filling, we may come up
> * short of fill.max. If a device was added, we'll have a return of
> * -EAGAIN above.
> */
> - if (!ret)
> + if (!ret) {
> hdr.count = fill.cur;
> + if (fill.require_devid)
> + hdr.flags = VFIO_PCI_HOT_RESET_FLAG_IOMMUFD_DEV_ID;
> + }
>
> reset_info_exit:
> if (copy_to_user(arg, &hdr, minsz))
> @@ -2346,12 +2392,10 @@ static bool vfio_dev_in_files(struct vfio_pci_core_device *vdev,
> static int vfio_pci_is_device_in_set(struct pci_dev *pdev, void *data)
> {
> struct vfio_device_set *dev_set = data;
> - struct vfio_device *cur;
>
> - list_for_each_entry(cur, &dev_set->device_list, dev_set_list)
> - if (cur->dev == &pdev->dev)
> - return 0;
> - return -EBUSY;
> + lockdep_assert_held(&dev_set->lock);
> +
> + return vfio_pci_find_device_in_devset(dev_set, pdev) ? 0 : -EBUSY;
> }
>
> /*
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 25432ef213ee..5a34364e3b94 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -650,11 +650,32 @@ enum {
> * VFIO_DEVICE_GET_PCI_HOT_RESET_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 12,
> * struct vfio_pci_hot_reset_info)
> *
> + * This command is used to query the affected devices in the hot reset for
> + * a given device. User could use the information reported by this command
> + * to figure out the affected devices among the devices it has opened.
> + * This command always reports the segment, bus and devfn information for
> + * each affected device, and selectively report the group_id or the dev_id
> + * per the way how the device being queried is opened.
> + * - If the device is opened via the traditional group/container manner,
> + * this command reports the group_id for each affected device.
> + *
> + * - If the device is opened as a cdev, this command needs to report
s/needs to report/reports
> + * dev_id for each affected device and set the
> + * VFIO_PCI_HOT_RESET_FLAG_IOMMUFD_DEV_ID flag. For the affected
> + * devices that are not opened as cdev or bound to different iommufds
> + * with the device that is queried, report an invalid dev_id to avoid
s/bound to different iommufds with the device that is queried/bound to
iommufds different from the reset device one?
> + * potential dev_id conflict as dev_id is local to iommufd. For such
> + * affected devices, user shall fall back to use the segment, bus and
> + * devfn info to map it to opened device.
> + *
> * Return: 0 on success, -errno on failure:
> * -enospc = insufficient buffer, -enodev = unsupported for device.
> */
> struct vfio_pci_dependent_device {
> - __u32 group_id;
> + union {
> + __u32 group_id;
> + __u32 dev_id;
> + };
> __u16 segment;
> __u8 bus;
> __u8 devfn; /* Use PCI_SLOT/PCI_FUNC */
> @@ -663,6 +684,7 @@ struct vfio_pci_dependent_device {
> struct vfio_pci_hot_reset_info {
> __u32 argsz;
> __u32 flags;
> +#define VFIO_PCI_HOT_RESET_FLAG_IOMMUFD_DEV_ID (1 << 0)
> __u32 count;
> struct vfio_pci_dependent_device devices[];
> };
Eric
next prev parent reply other threads:[~2023-04-05 12:19 UTC|newest]
Thread overview: 145+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-01 14:44 [Intel-gfx] [PATCH v3 00/12] Introduce new methods for verifying ownership in vfio PCI hot reset Yi Liu
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 01/12] vfio/pci: Update comment around group_fd get in vfio_pci_ioctl_pci_hot_reset() Yi Liu
2023-04-04 13:59 ` Eric Auger
2023-04-04 14:37 ` Liu, Yi L
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 02/12] vfio/pci: Only check ownership of opened devices in hot reset Yi Liu
2023-04-04 13:59 ` Eric Auger
2023-04-04 14:37 ` Liu, Yi L
2023-04-04 15:18 ` Eric Auger
2023-04-04 15:29 ` Liu, Yi L
2023-04-04 15:59 ` Eric Auger
2023-04-05 11:41 ` Jason Gunthorpe
2023-04-05 15:14 ` Eric Auger
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 03/12] vfio/pci: Move the existing hot reset logic to be a helper Yi Liu
2023-04-04 13:59 ` Eric Auger
2023-04-04 14:24 ` Liu, Yi L
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 04/12] vfio-iommufd: Add helper to retrieve iommufd_ctx and devid for vfio_device Yi Liu
2023-04-04 15:28 ` Eric Auger
2023-04-04 21:48 ` Alex Williamson
2023-04-21 7:11 ` Liu, Yi L
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 05/12] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET Yi Liu
2023-04-04 16:54 ` Eric Auger
2023-04-04 20:18 ` Alex Williamson
2023-04-05 7:55 ` Liu, Yi L
2023-04-05 8:01 ` Liu, Yi L
2023-04-05 15:36 ` Alex Williamson
2023-04-05 16:46 ` Jason Gunthorpe
2023-04-05 8:02 ` Eric Auger
2023-04-05 8:09 ` Liu, Yi L
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 06/12] vfio: Refine vfio file kAPIs for vfio PCI hot reset Yi Liu
2023-04-05 8:27 ` Eric Auger
2023-04-05 9:23 ` Liu, Yi L
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 07/12] vfio: Accpet device file from vfio PCI hot reset path Yi Liu
2023-04-04 20:31 ` Alex Williamson
2023-04-05 8:07 ` Eric Auger
2023-04-05 8:10 ` Liu, Yi L
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 08/12] vfio/pci: Renaming for accepting device fd in " Yi Liu
2023-04-04 21:23 ` Alex Williamson
2023-04-05 9:32 ` Eric Auger
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 09/12] vfio/pci: Accept device fd in VFIO_DEVICE_PCI_HOT_RESET ioctl Yi Liu
2023-04-05 9:36 ` Eric Auger
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 10/12] vfio: Mark cdev usage in vfio_device Yi Liu
2023-04-05 11:48 ` Eric Auger
2023-04-21 7:06 ` Liu, Yi L
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 11/12] iommufd: Define IOMMUFD_INVALID_ID in uapi Yi Liu
2023-04-04 21:00 ` Alex Williamson
2023-04-05 9:31 ` Liu, Yi L
2023-04-05 15:13 ` Alex Williamson
2023-04-05 15:17 ` Liu, Yi L
2023-04-05 11:46 ` Eric Auger
2023-04-01 14:44 ` [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO Yi Liu
2023-04-03 9:25 ` Liu, Yi L
2023-04-03 15:01 ` Alex Williamson
2023-04-03 15:22 ` Liu, Yi L
2023-04-03 15:32 ` Alex Williamson
2023-04-03 16:12 ` Jason Gunthorpe
2023-04-07 10:09 ` Liu, Yi L
2023-04-07 12:03 ` Alex Williamson
2023-04-07 13:24 ` Liu, Yi L
2023-04-07 13:51 ` Alex Williamson
2023-04-07 14:04 ` Liu, Yi L
2023-04-07 15:14 ` Alex Williamson
2023-04-07 15:47 ` Liu, Yi L
2023-04-07 21:07 ` Alex Williamson
2023-04-08 5:07 ` Liu, Yi L
2023-04-08 14:20 ` Alex Williamson
2023-04-09 11:58 ` Yi Liu
2023-04-09 13:29 ` Alex Williamson
2023-04-10 8:48 ` Liu, Yi L
2023-04-10 14:41 ` Alex Williamson
2023-04-10 15:18 ` Liu, Yi L
2023-04-10 15:23 ` Alex Williamson
2023-04-11 13:34 ` Jason Gunthorpe
2023-04-11 13:33 ` Jason Gunthorpe
2023-04-11 6:16 ` Liu, Yi L
2023-04-04 22:20 ` Alex Williamson
2023-04-05 12:19 ` Eric Auger [this message]
2023-04-05 14:04 ` Liu, Yi L
2023-04-05 16:25 ` Alex Williamson
2023-04-05 16:37 ` Jason Gunthorpe
2023-04-05 16:52 ` Alex Williamson
2023-04-05 17:23 ` Jason Gunthorpe
2023-04-05 18:56 ` Alex Williamson
2023-04-05 19:18 ` Alex Williamson
2023-04-05 19:21 ` Jason Gunthorpe
2023-04-05 19:49 ` Alex Williamson
2023-04-05 23:22 ` Jason Gunthorpe
2023-04-06 10:02 ` Liu, Yi L
2023-04-06 17:53 ` Alex Williamson
2023-04-07 10:09 ` Liu, Yi L
2023-04-11 13:24 ` Jason Gunthorpe
2023-04-11 15:54 ` Alex Williamson
2023-04-11 17:11 ` Alex Williamson
2023-04-11 18:40 ` Jason Gunthorpe
2023-04-11 21:58 ` Alex Williamson
2023-04-12 0:01 ` Jason Gunthorpe
2023-04-12 7:27 ` Tian, Kevin
2023-04-12 15:05 ` Jason Gunthorpe
2023-04-12 17:01 ` Alex Williamson
2023-04-13 2:57 ` Tian, Kevin
2023-04-12 10:09 ` Liu, Yi L
2023-04-12 16:54 ` Alex Williamson
2023-04-12 16:50 ` Alex Williamson
2023-04-12 20:06 ` Jason Gunthorpe
2023-04-13 8:25 ` Tian, Kevin
2023-04-13 11:50 ` Jason Gunthorpe
2023-04-13 14:35 ` Liu, Yi L
2023-04-13 14:41 ` Jason Gunthorpe
2023-04-13 18:07 ` Alex Williamson
2023-04-14 9:11 ` Tian, Kevin
2023-04-14 11:38 ` Liu, Yi L
2023-04-14 17:10 ` Alex Williamson
2023-04-17 4:20 ` Liu, Yi L
2023-04-17 19:01 ` Alex Williamson
2023-04-17 19:31 ` Jason Gunthorpe
2023-04-17 20:06 ` Alex Williamson
2023-04-18 3:24 ` Tian, Kevin
2023-04-18 4:10 ` Alex Williamson
2023-04-18 5:02 ` Tian, Kevin
2023-04-18 12:59 ` Jason Gunthorpe
2023-04-18 16:44 ` Alex Williamson
2023-04-18 10:34 ` Liu, Yi L
2023-04-18 16:49 ` Alex Williamson
2023-04-18 12:57 ` Jason Gunthorpe
2023-04-18 18:39 ` Alex Williamson
2023-04-20 12:10 ` Liu, Yi L
2023-04-20 14:08 ` Alex Williamson
2023-04-21 22:35 ` Jason Gunthorpe
2023-04-23 14:46 ` Liu, Yi L
2023-04-26 7:22 ` Liu, Yi L
2023-04-26 13:20 ` Alex Williamson
2023-04-26 15:08 ` Liu, Yi L
2023-04-14 16:34 ` Alex Williamson
2023-04-17 13:39 ` Jason Gunthorpe
2023-04-18 1:28 ` Tian, Kevin
2023-04-18 10:23 ` Liu, Yi L
2023-04-18 13:02 ` Jason Gunthorpe
2023-04-23 10:28 ` Liu, Yi L
2023-04-24 17:38 ` Jason Gunthorpe
2023-04-17 14:05 ` Jason Gunthorpe
2023-04-12 7:14 ` Tian, Kevin
2023-04-06 6:34 ` Liu, Yi L
2023-04-06 17:07 ` Alex Williamson
2023-04-05 17:58 ` Eric Auger
2023-04-06 5:31 ` Liu, Yi L
2023-04-01 14:47 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Introduce new methods for verifying ownership in vfio PCI hot reset (rev4) Patchwork
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=a937e622-ce32-6dda-d77c-7d8d76474ee0@redhat.com \
--to=eric.auger@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=chao.p.peng@linux.intel.com \
--cc=cohuck@redhat.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=jasowang@redhat.com \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=lulu@redhat.com \
--cc=mjrosato@linux.ibm.com \
--cc=nicolinc@nvidia.com \
--cc=peterx@redhat.com \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=terrence.xu@intel.com \
--cc=xudong.hao@intel.com \
--cc=yan.y.zhao@intel.com \
--cc=yanting.jiang@intel.com \
--cc=yi.l.liu@intel.com \
--cc=yi.y.sun@linux.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).