[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250828154419.5f4b15ff.alex.williamson@redhat.com>
Date: Thu, 28 Aug 2025 15:44:19 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: Masatake YAMATO <yamato@...hat.com>
Cc: linux-kernel@...r.kernel.org, ldv@...ace.io, kvm@...r.kernel.org
Subject: Re: [PATCH] vfio: show the name of IOMMU driver in
/proc/$pid/fdinfo
[Cc kvm@...r.kernel.org]
On Fri, 29 Aug 2025 05:21:00 +0900
Masatake YAMATO <yamato@...hat.com> wrote:
> The ops of VFIO overlap:
>
> (include/uapi/linux/vfio.h)
> #define VFIO_DEVICE_GET_PCI_HOT_RESET_INFO _IO(VFIO_TYPE, VFIO_BASE + 12)
> ...
> #define VFIO_MIG_GET_PRECOPY_INFO _IO(VFIO_TYPE, VFIO_BASE + 21)
> ...
> #define VFIO_IOMMU_DIRTY_PAGES _IO(VFIO_TYPE, VFIO_BASE + 17)
> #define VFIO_IOMMU_SPAPR_TCE_GET_INFO _IO(VFIO_TYPE, VFIO_BASE + 12)
> #define VFIO_EEH_PE_OP _IO(VFIO_TYPE, VFIO_BASE + 21)
> #define VFIO_IOMMU_SPAPR_REGISTER_MEMORY _IO(VFIO_TYPE, VFIO_BASE + 17)
> ...
> #define VFIO_IOMMU_SPAPR_TCE_REMOVE _IO(VFIO_TYPE, VFIO_BASE + 20)
>
> These overlapping makes strace decoding the ops and their arguments hard.
> See also https://lists.strace.io/pipermail/strace-devel/2021-May/010561.html
>
> This change adds "vfio-iommu-driver" field to /proc/$pid/fdinfo/$fd
> where $fd opens /dev/vfio/vfio. The value of the field helps strace
> decode the ops arguments.
>
> The prototype version of strace based on this change works fine:
> - https://lists.strace.io/pipermail/strace-devel/2021-August/010660.html
> - https://lists.strace.io/pipermail/strace-devel/2021-August/010660.html
Duplicate links.
We really only have type1 and spapr, and they're mutually exclusive per
architecture. POWER is spapr and everything else is type1. We're also
moving to using IOMMUFD and consider the vfio container to be somewhat
legacy, so we're not getting any new IOMMU backends for container mode.
The spapr support is also barely hanging on by a shoestring.
Is there current interest (ie. since 2021) for these changes? It
doesn't appear that even the RFC these changes were based on,
differentiating by file type, is in the current strace code base.
> Cc: Dmitry V. Levin <ldv@...ace.io>
> Signed-off-by: Masatake YAMATO <yamato@...hat.com>
> ---
> drivers/vfio/container.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/vfio/container.c b/drivers/vfio/container.c
> index d53d08f16973..03677fda49de 100644
> --- a/drivers/vfio/container.c
> +++ b/drivers/vfio/container.c
> @@ -11,6 +11,7 @@
> #include <linux/iommu.h>
> #include <linux/miscdevice.h>
> #include <linux/vfio.h>
> +#include <linux/seq_file.h>
> #include <uapi/linux/vfio.h>
>
> #include "vfio.h"
> @@ -384,12 +385,22 @@ static int vfio_fops_release(struct inode *inode, struct file *filep)
> return 0;
> }
#ifdef CONFIG_PROC_FS
> +static void vfio_fops_show_fdinfo(struct seq_file *m, struct file *filep)
> +{
> + struct vfio_container *container = filep->private_data;
> + struct vfio_iommu_driver *driver = container->iommu_driver;
> +
> + if (driver && driver->ops->name)
> + seq_printf(m, "vfio-iommu-driver:\t%s\n", driver->ops->name);
> +}
#endif
> +
> static const struct file_operations vfio_fops = {
> .owner = THIS_MODULE,
> .open = vfio_fops_open,
> .release = vfio_fops_release,
> .unlocked_ioctl = vfio_fops_unl_ioctl,
> .compat_ioctl = compat_ptr_ioctl,
#ifdef CONFIG_PROC_FS
> + .show_fdinfo = vfio_fops_show_fdinfo,
#endif
> };
>
> struct vfio_container *vfio_container_from_file(struct file *file)
proc.rst should also be updated. See [1] for a recent addition fdinfo.
Thanks,
Alex
[1]https://lore.kernel.org/r/20250804-show-fdinfo-v4-1-96b14c5691b3@fb.com
Powered by blists - more mailing lists