lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ