From: "Liu, Yi L" <yi.l.liu@intel.com>
To: "eric.auger@redhat.com" <eric.auger@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>
Cc: "jgg@nvidia.com" <jgg@nvidia.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"joro@8bytes.org" <joro@8bytes.org>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"cohuck@redhat.com" <cohuck@redhat.com>,
"nicolinc@nvidia.com" <nicolinc@nvidia.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
"yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
"peterx@redhat.com" <peterx@redhat.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
"shameerali.kolothum.thodi@huawei.com"
<shameerali.kolothum.thodi@huawei.com>,
"lulu@redhat.com" <lulu@redhat.com>,
"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
"intel-gvt-dev@lists.freedesktop.org"
<intel-gvt-dev@lists.freedesktop.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"Hao, Xudong" <xudong.hao@intel.com>,
"Zhao, Yan Y" <yan.y.zhao@intel.com>,
"Xu, Terrence" <terrence.xu@intel.com>,
"Jiang, Yanting" <yanting.jiang@intel.com>
Subject: RE: [PATCH v9 06/25] kvm/vfio: Accept vfio device file from userspace
Date: Fri, 7 Apr 2023 10:23:30 +0000 [thread overview]
Message-ID: <DS0PR11MB75295D9030BEF466A1F90F62C3969@DS0PR11MB7529.namprd11.prod.outlook.com> (raw)
In-Reply-To: <5f8d9e23-8a4c-3f97-8f22-01eaa4eddfbb@redhat.com>
Hi Eric,
> From: Eric Auger <eric.auger@redhat.com>
> Sent: Friday, April 7, 2023 4:57 PM
>
> Hi Yi,
>
> On 4/7/23 05:42, Liu, Yi L wrote:
> >> From: Alex Williamson <alex.williamson@redhat.com>
> >> Sent: Friday, April 7, 2023 2:58 AM
> >>>> You don't say anything about potential restriction, ie. what if the user calls
> >>>> KVM_DEV_VFIO_FILE with device fds while it has been using legacy
> >> container/group
> >>>> API?
> >>> legacy container/group path cannot do it as the below enhancement.
> >>> User needs to call KVM_DEV_VFIO_FILE before open devices, so this
> >>> should happen before _GET_DEVICE_FD. So the legacy path can never
> >>> pass device fds in KVM_DEV_VFIO_FILE.
> >>>
> >>>
> >>
> https://lore.kernel.org/kvm/20230327102059.333d6976.alex.williamson@redhat.com
> >> /#t
> >>
> >> Wait, are you suggesting that a comment in the documentation suggesting
> >> a usage policy somehow provides enforcement of that ordering?? That's
> >> not how this works. Thanks,
> > I don't know if there is a good way to enforce this order in the code. The
> > vfio_device->kvm pointer is optional. If it is NULL, vfio just ignores it.
> > So vfio doesn't have a good way to tell if the order requirement is met or
> > not. Perhaps just trigger NULL pointer dereference when kvm pointer is used
> > in the device drivers like kvmgt if this order is not met.
> >
> > So that's why I come up to document it here. The applications uses kvm
> > should know this and follow this otherwise it may encounter error.
> >
> > Do you have other suggestions for it? This order should be a generic
> > requirement. is it? group path also needs to follow it to make the mdev
> > driver that refers kvm pointer to be workable.
>
> In the same way as kvm_vfio_file_is_valid() called in kvm_vfio_file_add()
> can't you have a kernel API that checks the fd consistence?
I think we are talking about how to check if the order between
KVM_DEV_VFIO_FILE_ADD and the device open (e.g. invoked by
VFIO_GROUP_GET_DEVICE_FD) is met in the code rather than document
it here. Am I missing anything here? Maybe I've misunderstood Alex's
question. ☹
Regards,
Yi Liu
> Thanks
>
> Eric
> >
> > Thanks,
> > Yi Liu
> >
> >>>>> -The GROUP_ADD operation above should be invoked prior to accessing the
> >>>>> +The FILE/GROUP_ADD operation above should be invoked prior to accessing
> the
> >>>>> device file descriptor via VFIO_GROUP_GET_DEVICE_FD in order to support
> >>>>> drivers which require a kvm pointer to be set in their .open_device()
> >>>>> -callback.
> >>>>> +callback. It is the same for device file descriptor via character device
> >>>>> +open which gets device access via VFIO_DEVICE_BIND_IOMMUFD. For such
> file
> >>>>> +descriptors, FILE_ADD should be invoked before
> >> VFIO_DEVICE_BIND_IOMMUFD
> >>>>> +to support the drivers mentioned in prior sentence as well.
> >>> just as here. This means device fds can only be passed with KVM_DEV_VFIO_FILE
> >>> in the cdev path.
> >>>
> >>> Regards,
> >>> Yi Liu
next prev parent reply other threads:[~2023-04-07 10:23 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-01 15:18 [PATCH v9 00/25] Add vfio_device cdev for iommufd support Yi Liu
2023-04-01 15:18 ` [PATCH v9 01/25] vfio: Allocate per device file structure Yi Liu
2023-04-01 15:18 ` [PATCH v9 02/25] vfio: Refine vfio file kAPIs for KVM Yi Liu
2023-04-01 15:18 ` [PATCH v9 03/25] vfio: Remove vfio_file_is_group() Yi Liu
2023-04-05 12:20 ` Eric Auger
2023-04-01 15:18 ` [PATCH v9 04/25] vfio: Accept vfio device file in the KVM facing kAPI Yi Liu
2023-04-05 17:58 ` Eric Auger
2023-04-01 15:18 ` [PATCH v9 05/25] kvm/vfio: Rename kvm_vfio_group to prepare for accepting vfio device fd Yi Liu
2023-04-01 15:18 ` [PATCH v9 06/25] kvm/vfio: Accept vfio device file from userspace Yi Liu
2023-04-06 9:46 ` Eric Auger
2023-04-06 10:49 ` Liu, Yi L
2023-04-06 18:57 ` Alex Williamson
2023-04-07 3:42 ` Liu, Yi L
2023-04-07 8:56 ` Eric Auger
2023-04-07 10:23 ` Liu, Yi L [this message]
2023-04-01 15:18 ` [PATCH v9 07/25] vfio: Pass struct vfio_device_file * to vfio_device_open/close() Yi Liu
2023-04-06 12:43 ` Eric Auger
2023-04-01 15:18 ` [PATCH v9 08/25] vfio: Block device access via device fd until device is opened Yi Liu
2023-04-06 14:08 ` Eric Auger
2023-04-01 15:18 ` [PATCH v9 09/25] vfio: Add cdev_device_open_cnt to vfio_group Yi Liu
2023-04-06 14:13 ` Eric Auger
2023-04-01 15:18 ` [PATCH v9 10/25] vfio: Make vfio_device_open() single open for device cdev path Yi Liu
2023-04-06 16:44 ` Eric Auger
2023-04-07 9:48 ` Eric Auger
2023-04-07 10:18 ` Liu, Yi L
2023-04-01 15:18 ` [PATCH v9 11/25] vfio: Make vfio_device_first_open() to accept NULL iommufd for noiommu Yi Liu
2023-04-01 15:18 ` [PATCH v9 12/25] vfio-iommufd: Move noiommu support out of vfio_iommufd_bind() Yi Liu
2023-04-01 15:18 ` [PATCH v9 13/25] vfio-iommufd: Split bind/attach into two steps Yi Liu
2023-04-01 15:18 ` [PATCH v9 14/25] vfio: Record devid in vfio_device_file Yi Liu
2023-04-01 15:18 ` [PATCH v9 15/25] vfio-iommufd: Add detach_ioas support for physical VFIO devices Yi Liu
2023-04-01 15:18 ` [PATCH v9 16/25] iommufd/device: Add iommufd_access_detach() API Yi Liu
2023-04-04 22:45 ` Alex Williamson
2023-04-05 11:56 ` Jason Gunthorpe
2023-04-05 14:10 ` Liu, Yi L
2023-04-05 14:28 ` Jason Gunthorpe
2023-04-05 14:46 ` Liu, Yi L
2023-04-01 15:18 ` [PATCH v9 17/25] vfio-iommufd: Add detach_ioas support for emulated VFIO devices Yi Liu
2023-04-01 15:18 ` [PATCH v9 18/25] vfio: Determine noiommu in vfio_device registration Yi Liu
2023-04-01 15:18 ` [PATCH v9 19/25] vfio: Name noiommu vfio_device with "noiommu-" prefix Yi Liu
2023-04-01 15:18 ` [PATCH v9 20/25] vfio: Move vfio_device_group_unregister() to be the first operation in unregister Yi Liu
2023-04-01 15:18 ` [PATCH v9 21/25] vfio: Add cdev for vfio_device Yi Liu
2023-04-01 15:18 ` [PATCH v9 22/25] vfio: Add VFIO_DEVICE_BIND_IOMMUFD Yi Liu
2023-04-01 15:18 ` [PATCH v9 23/25] vfio: Add VFIO_DEVICE_[AT|DE]TACH_IOMMUFD_PT Yi Liu
2023-04-01 15:18 ` [PATCH v9 24/25] vfio: Compile group optionally Yi Liu
2023-04-01 15:18 ` [PATCH v9 25/25] docs: vfio: Add vfio device cdev description Yi Liu
2023-04-05 13:45 ` Eric Auger
2023-04-05 14:00 ` Liu, Yi L
2023-04-05 16:58 ` Alex Williamson
2023-04-07 8:44 ` Liu, Yi L
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=DS0PR11MB75295D9030BEF466A1F90F62C3969@DS0PR11MB7529.namprd11.prod.outlook.com \
--to=yi.l.liu@intel.com \
--cc=alex.williamson@redhat.com \
--cc=chao.p.peng@linux.intel.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=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.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).