; int intel_iommu_enabled = 0;
> EXPORT_SYMBOL_GPL(intel_iommu_enabled);
>
> -static int dmar_map_gfx = 1;
> static int intel_iommu_superpage = 1;
> static int iommu_identity_mapping;
> static int iommu_skip_te_disable;
> +static int disable_igfx_dedicated_iommu;
>
what about 'no_igfx_iommu"? dedicated is implied for igfx
so a shorter name might be slightly better.
otherwise it looks good:
Reviewed-by: Kevin Tian
> From: Lu Baolu
> Sent: Tuesday, January 30, 2024 2:08 PM
>
> Commit 62edf5dc4a524 ("intel-iommu: Restore DMAR_BROKEN_GFX_WA
> option for
> broken graphics drivers") was introduced 24 years ago as a temporary
> workaround for graphics drivers that used physical addresses for DMA and
> avoided DM
Posting here for visibility. I have tried up to the latest 6.6.2 kernel
with the same result.
https://bugzilla.redhat.com/show_bug.cgi?id=2248917
1. Please describe the problem:
All kernel versions after 6.4.12 are refusing to boot. I took this
error out of the logs:
```
Nov 05 17:56:01 fedora
> From: Liu, Yi L
> Sent: Wednesday, June 14, 2023 2:14 PM
>
>
> > With that I think Jason's suggestion is to lift that test into main.c:
> >
> > int vfio_register_group_dev(struct vfio_device *device)
> > {
> > /*
> > * VFIO always sets IOMMU_CACHE because we offer no way for
> userspa
> From: Liu, Yi L
> Sent: Wednesday, June 14, 2023 11:24 AM
>
> > From: Alex Williamson
> > Sent: Wednesday, June 14, 2023 4:11 AM
> >
> > On Tue, 13 Jun 2023 14:35:09 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Tue, Jun 13, 2023 at 11:15:11AM -0600, Alex Williamson wrote:
> > > > [Sorry for
> From: Liu, Yi L
> Sent: Wednesday, May 24, 2023 10:21 AM
>
> > >
> > > vfio_device_open_file()
> > > {
> > > dev_warn(device->dev, "vfio-noiommu device opened by user "
> > > "(%s:%d)\n", current->comm, task_pid_nr(current));
> > > }
> >
> > There needs to be a taint when VFIO_GR
> From: Liu, Yi L
> Sent: Thursday, May 18, 2023 9:26 PM
> > > +int vfio_iommufd_physical_devid(struct vfio_device *vdev)
> > > +{
> > > + if (vdev->iommufd_device)
> > > + return iommufd_device_to_id(vdev->iommufd_device);
> > > + if (vdev->noiommu_access)
> > > + return iommufd_a
> From: Liu, Yi L
> Sent: Friday, April 28, 2023 2:21 PM
>
> On 2023/4/28 02:32, Alex Williamson wrote:
> > On Thu, 27 Apr 2023 06:59:17 +
> > "Liu, Yi L" wrote:
> >
> >>> From: Tian, Kevin
> >>> Sent: Thursday, April 27, 2
> From: Liu, Yi L
> Sent: Wednesday, April 26, 2023 10:54 PM
>
> +static bool vfio_dev_in_iommufd_ctx(struct vfio_pci_core_device *vdev,
> + struct iommufd_ctx *iommufd_ctx)
> +{
> + struct iommufd_ctx *iommufd = vfio_iommufd_physical_ictx(&vdev-
> >vdev);
> +
> From: Liu, Yi L
> Sent: Wednesday, April 26, 2023 10:54 PM
> +
> +/*
> + * Check if a given iommu_group has been bound to an iommufd within a
> + * devset. Returns true if there is device in the devset which is in
> + * the input iommu_group and meanwhile bound to the input iommufd.
> + * Other
> From: Yi Liu
> Sent: Wednesday, April 26, 2023 10:54 PM
> +
> +/*
> + * Return devid for devices that have been bound with iommufd,
> + * returns 0 if not bound yet.
> + */
> +u32 vfio_iommufd_physical_devid(struct vfio_device *vdev)
> +{
> + if (WARN_ON(!vdev->iommufd_device && !vdev->iommuf
> From: Liu, Yi L
> Sent: Wednesday, April 26, 2023 10:54 PM
>
> VFIO needs two reserved values. 0 is already reserved by initializing
> xarray with XA_FLAGS_ALLOC1. This reserves -1 by limiting the xa alloc
> range.
>
> Signed-off-by: Yi Liu
> ---
> drivers/iommu/iommufd/main.c | 5 -
> 1
v.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
rpe
> Signed-off-by: Jason Gunthorpe
> Reviewed-by: Jason Gunthorpe
> Reviewed-by: Eric Auger
> Tested-by: Yanting Jiang
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Wednesday, April 26, 2023 10:54 PM
> @@ -121,7 +128,8 @@ static void vfio_emulated_unmap(void *data,
> unsigned long iova,
> {
> struct vfio_device *vdev = data;
>
> - if (vdev->ops->dma_unmap)
> + /* noiommu devices cannot do map/unmap */
> + if (vdev
> From: Liu, Yi L
> Sent: Wednesday, April 26, 2023 10:54 PM
>
> -static inline bool vfio_device_is_noiommu(struct vfio_device *vdev)
> +static inline int vfio_device_set_noiommu(struct vfio_device *device)
> {
> - return IS_ENABLED(CONFIG_VFIO_NOIOMMU) &&
> -vdev->group->type ==
> From: Alex Williamson
> Sent: Tuesday, April 18, 2023 12:11 PM
>
> On Tue, 18 Apr 2023 03:24:46 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Tuesday, April 18, 2023 4:07 AM
> > >
> > >
> From: Alex Williamson
> Sent: Tuesday, April 18, 2023 4:07 AM
>
> On Mon, 17 Apr 2023 16:31:56 -0300
> Jason Gunthorpe wrote:
>
> > On Mon, Apr 17, 2023 at 01:01:40PM -0600, Alex Williamson wrote:
> > > Yes, it's not trivial, but Jason is now proposing that we consider
> > > mixing groups, cd
> From: Jason Gunthorpe
> Sent: Monday, April 17, 2023 9:39 PM
>
> On Fri, Apr 14, 2023 at 09:11:30AM +, Tian, Kevin wrote:
>
> > The only corner case with this option is when a user mixes group
> > and cdev usages. iirc you mentioned it's a valid usage to be
> From: Alex Williamson
> Sent: Friday, April 14, 2023 2:07 AM
>
> We had already iterated a proposal where the group-id is replaced with
> a dev-id in the existing ioctl and a flag indicates when the return
> value is a dev-id vs group-id. This had a gap that userspace cannot
> determine if a r
oup id if VFIO_GROUP=y then same case.
For noiommu if VFIO_GROUP=n just do exact match based on BDF.
Either way the information returned by INFO is a superset of knowing
the reset scope between opened devices.
Thanks
Kevin
> From: Jason Gunthorpe
> Sent: Wednesday, April 12, 2023 11:06 PM
>
> On Wed, Apr 12, 2023 at 07:27:43AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, April 12, 2023 8:01 AM
> > >
> > > I see this prob
> From: Jason Gunthorpe
> Sent: Wednesday, April 12, 2023 8:01 AM
>
> I see this problem as a few basic requirements from a qemu-like
> application:
>
> 1) Does the configuration I was given support reset right now?
> 2) Will the configuration I was given support reset for the duration
> of
your earlier replies you pointed out the issue of unpredictable
ordering on a multi-function device e.g. upon which one runs first
dpdk or qmeu will block the other. But I wonder what is the actual use
of allowing both running while both can't do reset due to affected reset
scope in current model.
If a vfio user cannot do reset doesn't it imply it hasn't acquired the full
permission on the device then Jason's proposal of explicitly failing it
is actually a cleaner model?
Thanks
Kevin
> From: Jason Gunthorpe
> Sent: Thursday, March 30, 2023 4:00 AM
>
> On Mon, Mar 27, 2023 at 02:33:47AM -0700, Yi Liu wrote:
> > @@ -494,6 +479,30 @@ void iommufd_access_destroy(struct
> iommufd_access *access)
> > }
> > EXPORT_SYMBOL_NS_GPL(iommufd_access_destroy, IOMMUFD);
> >
> > +int iommuf
> From: Tian, Kevin
> Sent: Thursday, March 30, 2023 9:10 AM
>
> > From: Jason Gunthorpe
> > Sent: Wednesday, March 29, 2023 11:50 PM
> >
> > On Wed, Mar 29, 2023 at 09:41:26AM +, Tian, Kevin wrote:
> >
> > > We could extend bind_iommufd to re
> From: Jason Gunthorpe
> Sent: Wednesday, March 29, 2023 11:58 PM
>
> On Wed, Mar 29, 2023 at 09:49:44AM -0600, Alex Williamson wrote:
>
> > > We could extend bind_iommufd to return the group id or introduce a
> > > new ioctl to query it per dev_id.
> >
> > That would be ironic to go to all thi
> From: Jason Gunthorpe
> Sent: Wednesday, March 29, 2023 11:50 PM
>
> On Wed, Mar 29, 2023 at 09:41:26AM +, Tian, Kevin wrote:
>
> > We could extend bind_iommufd to return the group id or introduce a
> > new ioctl to query it per dev_id.
>
> > Once th
so needs such knowledge when
constructing guest topology.
with fd passed in Qemu has no way to associate the fd to a group.
We could extend bind_iommufd to return the group id or introduce a
new ioctl to query it per dev_id.
Once that is in place looks we don't need a new _INFO ioctl?
Thanks
Kevin
> From: Liu, Yi L
> Sent: Monday, March 27, 2023 5:41 PM
>
> For noiommu device, vfio core names the cdev node with prefix "noiommu-".
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Monday, March 27, 2023 5:41 PM
>
> This adds a noiommu flag in vfio_device, hence caller of the
> vfio_device_is_noiommu() just refers to the flag for noiommu
> check.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Tuesday, March 28, 2023 11:32 AM
>
> > From: Alex Williamson
> > Sent: Tuesday, March 28, 2023 3:26 AM
> >
> > Additionally, VFIO_DEVICE_GET_PCI_HOT_RESET_INFO has a flags arg that
> > isn't used, why do we need a new ioctl vs defining
> > VFIO_PCI_HOT_RESET_FLAG_IOMMUF
> From: Liu, Yi L
> Sent: Monday, March 27, 2023 5:34 PM
>
> no need to pass the iommufd_ucmd pointer.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Alex Williamson
> Sent: Wednesday, March 22, 2023 5:01 AM
>
> On Tue, 21 Mar 2023 17:50:08 -0300
> Jason Gunthorpe wrote:
>
> >
> > Though it would be nice if qemu didn't need two implementations so Yi
> > I'd rather see a new info in this series as well and qemu can just
> > consistent
> From: Jason Gunthorpe
> Sent: Tuesday, March 21, 2023 1:17 AM
>
> On Mon, Mar 20, 2023 at 10:31:53PM +0800, Yi Liu wrote:
> > On 2023/3/20 22:09, Jason Gunthorpe wrote:
> > > On Wed, Mar 15, 2023 at 04:40:19AM +, Liu, Yi L wrote:
> > >
> > > > # if IS_ENABLED(CONFIG_VFIO_GROUP)
> > > > stat
> From: Liu, Yi L
> Sent: Friday, March 17, 2023 11:07 AM
>
> > From: Tian, Kevin
> > Sent: Friday, March 17, 2023 10:14 AM
> >
> > > From: Liu, Yi L
> > > Sent: Thursday, March 16, 2023 8:55 PM
> > >
> > > +
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:56 PM
>
> This gives notes for userspace applications on device cdev usage.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> + return -EPERM;
> +
> + return 0;
> +}
it makes more sense to check CAP first.
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:55 PM
> +
> +void vfio_iommufd_emulated_detach_ioas(struct vfio_device *vdev)
> +{
> + lockdep_assert_held(&vdev->dev_set->lock);
> +
> + if (WARN_ON(!vdev->iommufd_access) || !vdev->iommufd_attached)
> + return;
> +
ditto t
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:55 PM
>
> +void vfio_iommufd_physical_detach_ioas(struct vfio_device *vdev)
> +{
> + lockdep_assert_held(&vdev->dev_set->lock);
> +
> + if (WARN_ON(!vdev->iommufd_device) || !vdev->iommufd_attached)
> + return;
> +
the 2nd
s_unpin_pages() callback to happen via
> this unmap() call, add an ioas_unpin pointer, so the unpin routine won't
> be affected by the "access->ioas = NULL" trick.
>
> Signed-off-by: Nicolin Chen
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:55 PM
>
> to align with the coming vfio device cdev support.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
gt; + if (device->group->iommufd && vfio_device_is_noiommu(device)) {
> + if (device->open_count == 0) {
> + ret =
> vfio_iommufd_enable_noiommu_compat(device,
> + device-
> >
gt; support in device cdev path it's extended to allow both being NULL. The
> caller is expected to verify noiommu permission before passing NULL
> to this function.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
-by: Nicolin Chen
> Tested-by: Matthew Rosato
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:55 PM
>
> since no user of vfio_file_is_group() now.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
Yi Liu
this may be adjusted upon whether zero-length approach will be included
finally.
but on its own:
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:42 PM
>
> This extends both vfio_file_is_valid() and vfio_file_has_dev() to accept
> device file from the vfio PCI hot reset.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:42 PM
>
> This prepares vfio core to accept vfio device file from the vfio PCI
> hot reset path. vfio_file_is_group() is still kept for KVM usage.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
Otherwise all opened devices in the dev_set must be
> - * contained by the set of groups provided by the user.
> + * contained by the set of groups/devices provided by
> + * the user.
just a nit. You may want to add "devices" in the last patch.
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:42 PM
>
> as an alternative method for ownership check when iommufd is used. In
> this case all opened devices in the affected dev_set are verified to
> be bound to a same valid iommufd value to allow reset. It's simpler
> and faster as user do
ason Gunthorpe
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
to
> represent the device/iommufd bond.
>
> Reviewed-by: Jason Gunthorpe
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
eviewed-by: Jason Gunthorpe
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Alex Williamson
> Sent: Friday, March 17, 2023 8:23 AM
>
> On Thu, 16 Mar 2023 23:29:21 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Friday, March 17, 2023 2:46 AM
> > >
> > > On Wed, 15 Mar 2023
> From: Alex Williamson
> Sent: Friday, March 17, 2023 2:46 AM
>
> On Wed, 15 Mar 2023 23:31:23 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Thursday, March 16, 2023 6:53 AM
> > > I'm afraid this pro
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 11:55 AM
>
> > From: Tian, Kevin
> > Sent: Thursday, March 16, 2023 7:31 AM
> >
> > > From: Alex Williamson
> > > Sent: Thursday, March 16, 2023 6:53 AM
> > >
> > > On Wed, 8 Mar
> From: Nicolin Chen
> Sent: Thursday, March 16, 2023 1:44 PM
>
> On Thu, Mar 16, 2023 at 05:38:41AM +, Tian, Kevin wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > > From: Nicolin Chen
> > > Sent: Thurs
> From: Nicolin Chen
> Sent: Thursday, March 16, 2023 1:33 PM
>
> Hi Kevin,
>
> I've fixed the other two commits. Here is the one that I am
> not sure about:
>
> On Thu, Mar 16, 2023 at 02:53:50AM +, Tian, Kevin wrote:
>
> > > [2] This add
> From: Nicolin Chen
> Sent: Wednesday, March 15, 2023 5:03 PM
>
> Hi,
>
> On Wed, Mar 15, 2023 at 06:50:53AM +, Tian, Kevin wrote:
>
> > > So, this preparatory series will add a pair of simple attach()
> > > and detach() APIs. Then the cdev se
> From: Liu, Yi L
> Sent: Wednesday, March 15, 2023 4:53 PM
>
> > From: Tian, Kevin
> > Sent: Wednesday, March 15, 2023 2:52 PM
> >
> > > From: Nicolin Chen
> > > Sent: Wednesday, March 15, 2023 2:22 PM
> > >
> > > On Wed, Mar 15
> From: Alex Williamson
> Sent: Thursday, March 16, 2023 6:53 AM
>
> On Wed, 8 Mar 2023 05:28:51 -0800
> Yi Liu wrote:
>
> > This is another method to issue PCI hot reset for the users that bounds
> > device to a positive iommufd value. In such case, iommufd is a proof of
> > device ownership.
> From: Liu, Yi L
> Sent: Wednesday, March 15, 2023 12:40 PM
>
> > From: Tian, Kevin
> > Sent: Friday, March 10, 2023 6:07 PM
> >
> > > From: Liu, Yi L
> > > Sent: Friday, March 10, 2023 5:58 PM
> > >
> > > &g
> From: Nicolin Chen
> Sent: Wednesday, March 15, 2023 2:22 PM
>
> On Wed, Mar 15, 2023 at 06:16:37AM +, Tian, Kevin wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > > From: Nicolin Chen
> > > Sent: Wednesday, M
> From: Nicolin Chen
> Sent: Wednesday, March 15, 2023 2:33 PM
>
> On Wed, Mar 15, 2023 at 06:15:23AM +, Tian, Kevin wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > > From: Nicolin Chen
> > > Sent: Wednesday, M
> From: Nicolin Chen
> Sent: Wednesday, March 15, 2023 2:51 AM
>
> On Fri, Mar 10, 2023 at 02:08:15AM +, Tian, Kevin wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > > From: Liu, Yi L
> > > Sent: Wednesday, Marc
> From: Nicolin Chen
> Sent: Wednesday, March 15, 2023 9:01 AM
>
> Hi Jason/Kevin,
>
> >
> > Perhaps we can have iommufd_access_attach/detach in this series
> > along with a vfio_iommufd_emulated_detach_ioas, and the locking
> > will come with another patc
> From: Liu, Yi L
> Sent: Saturday, March 11, 2023 6:24 PM
> > > >
> > > > - ret = vdev->ops->bind_iommufd(vdev, ictx, &device_id);
> > > > - if (ret)
> > > > - return ret;
> > > > + /* The legacy path has no way to return the device id */
> > > > + return vde
> From: Jason Gunthorpe
> Sent: Friday, March 10, 2023 10:04 PM
>
> On Fri, Mar 10, 2023 at 02:15:32AM +, Tian, Kevin wrote:
> > > From: Liu, Yi L
> > > Sent: Wednesday, March 8, 2023 9:14 PM
> > >
> > > After making the no-DMA drivers (sample
> From: Liu, Yi L
> Sent: Friday, March 10, 2023 5:58 PM
>
> > From: Tian, Kevin
> > Sent: Friday, March 10, 2023 5:02 PM
> >
> > > From: Liu, Yi L
> > > Sent: Wednesday, March 8, 2023 9:29 PM
> > > +
> > > +stati
> From: Liu, Yi L
> Sent: Friday, March 10, 2023 4:22 PM
>
> >
> > > +int vfio_iommufd_attach_compat_ioas(struct vfio_device *vdev,
> > > + struct iommufd_ctx *ictx)
> > > +{
> > > + u32 ioas_id;
> > > + int ret;
> > > +
> > > + lockdep_assert_held(&vdev->dev_set->lock
> From: Liu, Yi L
> Sent: Friday, March 10, 2023 2:04 PM
> > > + *
> > > + * In the last case all affected devices which are opened by this user
> > > + * must have been bound to a same iommufd_ctx. This approach is only
> > > + * available for devices bound to positive iommufd.
> >
> > As we cha
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> group code is not needed for vfio device cdev, so with vfio device cdev
> introduced, the group infrastructures can be compiled out if only cdev
> is needed.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
> +
> +static int vfio_device_cdev_probe_noiommu(struct vfio_device *device)
> +{
> + struct iommu_group *iommu_group;
> + int ret = 0;
> +
> + if (!IS_ENABLED(CONFIG_VFIO_NOIOMMU) || !vfio_noiommu)
> + return -EINV
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> + /*
> + * Placing it before vfio_device_put_registration() to prevent
> + * new registration refcount increment by
> VFIO_GROUP_GET_DEVICE_FD
> + * during the unregister time.
> + */
> + vfio_device_group_
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> bind_iommufd() will generate an ID to represent this bond, it is needed
> by userspace for further usage. devid is stored in vfio_device_file to
> avoid passing devid pointer in multiple places.
after removing vfio_iommufd_bind() the
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> +/*
> + * This shall be used without group lock as group and group->container
> + * should be fixed before group is set to df->group.
> + */
/* No group lock since df->group and df->group->container cannot change */
> +bool vfio_dev
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> @@ -177,7 +177,7 @@ static int vfio_device_group_open(struct
> vfio_device_file *df)
> mutex_lock(&device->group->group_lock);
> if (!vfio_group_has_iommu(device->group)) {
> ret = -EINVAL;
> - go
> From: Yi Liu
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> This is another method to issue PCI hot reset for the users that bounds
> device to a positive iommufd value. In such case, iommufd is a proof of
> device ownership. By passing a zero-length fd array, user indicates kernel
> to do ownersh
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> @@ -1319,8 +1319,14 @@ static int vfio_pci_ioctl_pci_hot_reset(struct
> vfio_pci_core_device *vdev,
> break;
> }
>
> - /* Ensure the FD is a vfio group FD.*/
> - if (!vfio_f
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> No function change is intended, just to make the helpers and structures
> to be prepared to accept device fds as proof of device ownership.
>
> Signed-off-by: Yi Liu
> ---
> drivers/vfio/pci/vfio_pci_core.c | 40 ---
is safe, because
* dev_set->lock is held in hot reset path so this device
* cannot race being opened by another user simultaneously.
*
* Otherwise all opened devices in the dev_set must be
* contained by the set of groups provided by the user.
the rest looks good:
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> @@ -1114,6 +1114,10 @@ static long vfio_device_fops_unl_ioctl(struct file
> *filep,
> struct vfio_device *device = df->device;
> int ret;
>
> + /* Paired with smp_store_release() in vfio_device_group_open() */
> +
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:14 PM
>
> After making the no-DMA drivers (samples/vfio-mdev) providing iommufd
> callbacks, __vfio_register_dev() should check the presence of the iommufd
> callbacks if CONFIG_IOMMUFD is enabled.
>
> Signed-off-by: Yi Liu
> ---
> drivers/v
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:14 PM
>
> @@ -32,12 +32,8 @@ int vfio_iommufd_bind(struct vfio_device *vdev,
> struct iommufd_ctx *ictx)
> return 0;
> }
>
> - /*
> - * If the driver doesn't provide this op then it means the device does
> - *
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:14 PM
>
> vfio device cdev needs to return iommufd_access ID to userspace if
> bind_iommufd succeeds.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:14 PM
>
> @@ -449,33 +450,18 @@ iommufd_access_create(struct iommufd_ctx *ictx,
> u32 ioas_id,
> access->data = data;
> access->ops = ops;
>
> - obj = iommufd_get_object(ictx, ioas_id, IOMMUFD_OBJ_IOAS);
> - if (IS_ERR(obj))
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 4:01 PM
>
> > From: Tian, Kevin
> > Sent: Wednesday, March 8, 2023 3:55 PM
> >
> > > From: Liu, Yi L
> > > Sent: Wednesday, March 8, 2023 3:47 PM
> > >
> > > >
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 3:47 PM
>
> > From: Tian, Kevin
> > Sent: Wednesday, March 8, 2023 3:26 PM
> >
> > > From: Liu, Yi L
> > > Sent: Tuesday, March 7, 2023 9:29 PM
> > >
> > > >
> >
> From: Liu, Yi L
> Sent: Tuesday, March 7, 2023 9:29 PM
>
> >
> > I really prefer the 'use the iommufd option' still exist, it is so
> > much cleaner and easier for the actual users of this API. We've lost
> > the point by worrying about no iommu.
>
> Hmmm, so you are suggesting to have both th
> From: Liu, Yi L
> Sent: Tuesday, March 7, 2023 9:04 PM
>
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 7, 2023 8:38 PM
> >
> > On Tue, Mar 07, 2023 at 06:38:59AM +, Tian, Kevin wrote:
> > > > From: Liu, Yi L
> > > > Sent: Fr
> From: Liu, Yi L
> Sent: Friday, March 3, 2023 2:58 PM
>
> > What should we return here anyhow if an access was created?
>
> iommufd_access->obj.id. should be fine. Is it?
>
Thinking more I'm not sure whether it's a good idea to fill the
dev_id field with an access object id and then later co
> From: Jason Gunthorpe
> Sent: Monday, March 6, 2023 9:17 PM
>
> On Fri, Mar 03, 2023 at 09:55:42AM -0700, Alex Williamson wrote:
>
> > I can't think of a reason DPDK couldn't use hot-reset. If we want to
> > make it a policy, it should be enforced by code, but creating that
> > policy based o
> From: Tian, Kevin
> Sent: Monday, March 6, 2023 4:17 PM
>
> > From: Liu, Yi L
> > Sent: Sunday, March 5, 2023 10:49 PM
> >
> >
> > How about falling back to prior solution. Allow userspace to pass a set
> > of device fd, and the kernel just chec
> From: Liu, Yi L
> Sent: Sunday, March 5, 2023 10:49 PM
>
> > From: Alex Williamson
> > Sent: Saturday, March 4, 2023 12:56 AM
> >
> > On Fri, 3 Mar 2023 06:36:35 +
> > "Tian, Kevin" wrote:
> >
> > > use of noiommu should be
> From: Liu, Yi L
> Sent: Thursday, March 2, 2023 10:20 PM
>
> > From: Jason Gunthorpe
> > Sent: Thursday, March 2, 2023 8:35 PM
> >
> > On Thu, Mar 02, 2023 at 09:55:46AM +, Tian, Kevin wrote:
> > > > From: Liu, Yi L
> From: Liu, Yi L
> Sent: Thursday, March 2, 2023 2:07 PM
>
> > - if (!vfio_dev_in_groups(cur_vma, groups)) {
> > + if (cur_vma->vdev.open_count &&
> > + !vfio_dev_in_groups(cur_vma, groups) &&
> > + !vfio_dev_in_iommufd_ctx(cur_vma, iommufd_ctx)) {
> From: Liu, Yi L
> Sent: Friday, February 24, 2023 11:44 AM
> > > Upon reflection we can probably make it even simpler and just have a 0
> > > length fd array mean to use the iommufd the vfio_device is already
> > > associated with
> > >
> > > And the check for correctness can be simplified to si
> From: Jason Gunthorpe
> Sent: Friday, February 24, 2023 10:36 AM
>
> On Fri, Feb 24, 2023 at 02:21:33AM +, Tian, Kevin wrote:
>
> > Yi, while you are incorporating this change please also update the
> > uapi header. Rename 'group_fds[]' to 'fds
1 - 100 of 446 matches
Mail list logo
