From: Jason Gunthorpe <jgg@nvidia.com>
To: Yi Liu <yi.l.liu@intel.com>, alex.williamson@redhat.com
Cc: mjrosato@linux.ibm.com, jasowang@redhat.com,
xudong.hao@intel.com, zhenzhong.duan@intel.com,
peterx@redhat.com, terrence.xu@intel.com,
chao.p.peng@linux.intel.com, linux-s390@vger.kernel.org,
kvm@vger.kernel.org, lulu@redhat.com, yanting.jiang@intel.com,
joro@8bytes.org, nicolinc@nvidia.com, kevin.tian@intel.com,
yan.y.zhao@intel.com, intel-gfx@lists.freedesktop.org,
eric.auger@redhat.com, intel-gvt-dev@lists.freedesktop.org,
yi.y.sun@linux.intel.com, clegoate@redhat.com, cohuck@redhat.com,
shameerali.kolothum.thodi@huawei.com,
suravee.suthikulpanit@amd.com, robin.murphy@arm.com
Subject: Re: [Intel-gfx] [PATCH v15 00/26] Add vfio_device cdev for iommufd support
Date: Tue, 18 Jul 2023 13:57:46 -0300 [thread overview]
Message-ID: <ZLbEigQvwSZFiCqv@nvidia.com> (raw)
In-Reply-To: <20230718135551.6592-1-yi.l.liu@intel.com>
On Tue, Jul 18, 2023 at 06:55:25AM -0700, Yi Liu wrote:
> Existing VFIO provides group-centric user APIs for userspace. Userspace
> opens the /dev/vfio/$group_id first before getting device fd and hence
> getting access to device. This is not the desired model for iommufd. Per
> the conclusion of community discussion[1], iommufd provides device-centric
> kAPIs and requires its consumer (like VFIO) to be device-centric user
> APIs. Such user APIs are used to associate device with iommufd and also
> the I/O address spaces managed by the iommufd.
>
> This series first introduces a per device file structure to be prepared
> for further enhancement and refactors the kvm-vfio code to be prepared
> for accepting device file from userspace. After this, adds a mechanism for
> blocking device access before iommufd bind. Then refactors the vfio to be
> able to handle cdev paths (e.g. iommufd binding, no-iommufd, [de]attach ioas).
> This refactor includes making the device_open exclusive between the group
> and the cdev path, only allow single device open in cdev path; vfio-iommufd
> code is also refactored to support cdev. e.g. split the vfio_iommufd_bind()
> into two steps. Eventually, adds the cdev support for vfio device and the
> new ioctls, then makes group infrastructure optional as it is not needed
> when vfio device cdev is compiled.
>
> This series is based on some preparation works done to vfio emulated devices[2]
> and vfio pci hot reset enhancements[3]. Per discussion[4], this series does not
> support cdev for physical devices that do not have IOMMU. Such devices only
> have group-centric user APIs.
>
> This series is a prerequisite for iommu nesting for vfio device[5] [6].
>
> The complete code can be found in below branch, simple tests done to the
> legacy group path and the cdev path. QEMU changes are in upstreaming[7]
> and the complete code can be found at[8]
>
> https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v15
> (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y)
Alex, if you are still good with this lets make this into a shared
branch, do you want to do it or would you like a PR from me?
Thanks,
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Yi Liu <yi.l.liu@intel.com>, alex.williamson@redhat.com
Cc: kevin.tian@intel.com, joro@8bytes.org, robin.murphy@arm.com,
cohuck@redhat.com, eric.auger@redhat.com, nicolinc@nvidia.com,
kvm@vger.kernel.org, mjrosato@linux.ibm.com,
chao.p.peng@linux.intel.com, yi.y.sun@linux.intel.com,
peterx@redhat.com, jasowang@redhat.com,
shameerali.kolothum.thodi@huawei.com, lulu@redhat.com,
suravee.suthikulpanit@amd.com,
intel-gvt-dev@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, linux-s390@vger.kernel.org,
xudong.hao@intel.com, yan.y.zhao@intel.com,
terrence.xu@intel.com, yanting.jiang@intel.com,
zhenzhong.duan@intel.com, clegoate@redhat.com
Subject: Re: [PATCH v15 00/26] Add vfio_device cdev for iommufd support
Date: Tue, 18 Jul 2023 13:57:46 -0300 [thread overview]
Message-ID: <ZLbEigQvwSZFiCqv@nvidia.com> (raw)
In-Reply-To: <20230718135551.6592-1-yi.l.liu@intel.com>
On Tue, Jul 18, 2023 at 06:55:25AM -0700, Yi Liu wrote:
> Existing VFIO provides group-centric user APIs for userspace. Userspace
> opens the /dev/vfio/$group_id first before getting device fd and hence
> getting access to device. This is not the desired model for iommufd. Per
> the conclusion of community discussion[1], iommufd provides device-centric
> kAPIs and requires its consumer (like VFIO) to be device-centric user
> APIs. Such user APIs are used to associate device with iommufd and also
> the I/O address spaces managed by the iommufd.
>
> This series first introduces a per device file structure to be prepared
> for further enhancement and refactors the kvm-vfio code to be prepared
> for accepting device file from userspace. After this, adds a mechanism for
> blocking device access before iommufd bind. Then refactors the vfio to be
> able to handle cdev paths (e.g. iommufd binding, no-iommufd, [de]attach ioas).
> This refactor includes making the device_open exclusive between the group
> and the cdev path, only allow single device open in cdev path; vfio-iommufd
> code is also refactored to support cdev. e.g. split the vfio_iommufd_bind()
> into two steps. Eventually, adds the cdev support for vfio device and the
> new ioctls, then makes group infrastructure optional as it is not needed
> when vfio device cdev is compiled.
>
> This series is based on some preparation works done to vfio emulated devices[2]
> and vfio pci hot reset enhancements[3]. Per discussion[4], this series does not
> support cdev for physical devices that do not have IOMMU. Such devices only
> have group-centric user APIs.
>
> This series is a prerequisite for iommu nesting for vfio device[5] [6].
>
> The complete code can be found in below branch, simple tests done to the
> legacy group path and the cdev path. QEMU changes are in upstreaming[7]
> and the complete code can be found at[8]
>
> https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v15
> (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y)
Alex, if you are still good with this lets make this into a shared
branch, do you want to do it or would you like a PR from me?
Thanks,
Jason
next prev parent reply other threads:[~2023-07-18 16:57 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-18 13:55 [Intel-gfx] [PATCH v15 00/26] Add vfio_device cdev for iommufd support Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 01/26] vfio: Allocate per device file structure Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 02/26] vfio: Refine vfio file kAPIs for KVM Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 03/26] vfio: Accept vfio device file in the KVM facing kAPI Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 04/26] kvm/vfio: Prepare for accepting vfio device fd Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 05/26] kvm/vfio: Accept vfio device file from userspace Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 06/26] vfio: Pass struct vfio_device_file * to vfio_device_open/close() Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 07/26] vfio: Block device access via device fd until device is opened Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 08/26] vfio: Add cdev_device_open_cnt to vfio_group Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 09/26] vfio: Make vfio_df_open() single open for device cdev path Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 10/26] vfio-iommufd: Move noiommu compat validation out of vfio_iommufd_bind() Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 11/26] vfio-iommufd: Split bind/attach into two steps Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 12/26] vfio: Record devid in vfio_device_file Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 13/26] vfio-iommufd: Add detach_ioas support for physical VFIO devices Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 14/26] iommufd/device: Add iommufd_access_detach() API Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 15/26] vfio-iommufd: Add detach_ioas support for emulated VFIO devices Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 16/26] vfio: Move vfio_device_group_unregister() to be the first operation in unregister Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 17/26] vfio: Move device_del() before waiting for the last vfio_device registration refcount Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 18/26] vfio: Add cdev for vfio_device Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 19/26] vfio: Test kvm pointer in _vfio_device_get_kvm_safe() Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 20/26] iommufd: Add iommufd_ctx_from_fd() Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 16:55 ` [Intel-gfx] " Jason Gunthorpe
2023-07-18 16:55 ` Jason Gunthorpe
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 21/26] vfio: Avoid repeated user pointer cast in vfio_device_fops_unl_ioctl() Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 22/26] vfio: Add VFIO_DEVICE_BIND_IOMMUFD Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 16:56 ` [Intel-gfx] " Jason Gunthorpe
2023-07-18 16:56 ` Jason Gunthorpe
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 23/26] vfio: Add VFIO_DEVICE_[AT|DE]TACH_IOMMUFD_PT Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 24/26] vfio: Move the IOMMU_CAP_CACHE_COHERENCY check in __vfio_register_dev() Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 25/26] vfio: Compile vfio_group infrastructure optionally Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 13:55 ` [Intel-gfx] [PATCH v15 26/26] docs: vfio: Add vfio device cdev description Yi Liu
2023-07-18 13:55 ` Yi Liu
2023-07-18 15:55 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Add vfio_device cdev for iommufd support (rev19) Patchwork
2023-07-18 16:57 ` Jason Gunthorpe [this message]
2023-07-18 16:57 ` [PATCH v15 00/26] Add vfio_device cdev for iommufd support Jason Gunthorpe
2023-07-24 19:09 ` [Intel-gfx] " Alex Williamson
2023-07-24 19:09 ` Alex Williamson
2023-07-25 18:00 ` [Intel-gfx] " Alex Williamson
2023-07-25 18:00 ` Alex Williamson
2023-07-26 13:39 ` [Intel-gfx] " Jason Gunthorpe
2023-07-26 13:39 ` Jason Gunthorpe
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=ZLbEigQvwSZFiCqv@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=chao.p.peng@linux.intel.com \
--cc=clegoate@redhat.com \
--cc=cohuck@redhat.com \
--cc=eric.auger@redhat.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=jasowang@redhat.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 \
--cc=zhenzhong.duan@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 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.