From: Jason Gunthorpe <jgg@nvidia.com> To: Niklas Schnelle <schnelle@linux.ibm.com> Cc: Alex Williamson <alex.williamson@redhat.com>, Lu Baolu <baolu.lu@linux.intel.com>, Chaitanya Kulkarni <chaitanyak@nvidia.com>, Cornelia Huck <cohuck@redhat.com>, Daniel Jordan <daniel.m.jordan@oracle.com>, David Gibson <david@gibson.dropbear.id.au>, Eric Auger <eric.auger@redhat.com>, iommu@lists.linux-foundation.org, Jason Wang <jasowang@redhat.com>, Jean-Philippe Brucker <jean-philippe@linaro.org>, Joao Martins <joao.m.martins@oracle.com>, Kevin Tian <kevin.tian@intel.com>, kvm@vger.kernel.org, Matthew Rosato <mjrosato@linux.ibm.com>, "Michael S. Tsirkin" <mst@redhat.com>, Nicolin Chen <nicolinc@nvidia.com>, Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>, Yi Liu <yi.l.liu@intel.com>, Keqian Zhu <zhukeqian1@huawei.com> Subject: Re: [PATCH RFC 03/12] iommufd: File descriptor, context, kconfig and makefiles Date: Tue, 22 Mar 2022 11:50:36 -0300 [thread overview] Message-ID: <20220322145036.GG11336@nvidia.com> (raw) In-Reply-To: <5f1e2f85e45d7cc5c7cade7042a681186d3d7bd3.camel@linux.ibm.com> On Tue, Mar 22, 2022 at 03:18:51PM +0100, Niklas Schnelle wrote: > On Fri, 2022-03-18 at 14:27 -0300, Jason Gunthorpe wrote: > > This is the basic infrastructure of a new miscdevice to hold the iommufd > > IOCTL API. > > > > It provides: > > - A miscdevice to create file descriptors to run the IOCTL interface over > > > > - A table based ioctl dispatch and centralized extendable pre-validation > > step > > > > - An xarray mapping user ID's to kernel objects. The design has multiple > > inter-related objects held within in a single IOMMUFD fd > > > > - A simple usage count to build a graph of object relations and protect > > against hostile userspace racing ioctls > > For me at this point it seems hard to grok what this "graph of object > relations" is about. Maybe an example would help? I'm assuming this is > about e.g. the DEVICE -depends-on-> HW_PAGETABLE -depends-on-> IOAS so > the arrows in the picture of PATCH 02? Yes, it is basically standard reference relations, think 'kref'. Object A referenced B because A has a pointer to B in its struct. Therefore B cannot be destroyed before A without creating a dangling reference. > Or is it the other way around > and the IOAS -depends-on-> HW_PAGETABLE because it's about which > references which? From the rest of the patch I seem to understand that > this mostly establishes the order of destruction. So is HW_PAGETABLE > destroyed before the IOAS because a HW_PAGETABLE must never reference > an invalid/destoryed IOAS or is it the other way arund because the IOAS > has a reference to the HW_PAGETABLES in it? I'd guess the former but > I'm a bit confused still. Yes HW_PAGETABLE is first because it is responsible to remove the iommu_domain from the IOAS and the IOAS cannot be destroyed with iommu_domains in it. > > +/* > > + * The objects for an acyclic graph through the users refcount. This enum must > > + * be sorted by type depth first so that destruction completes lower objects and > > + * releases the users refcount before reaching higher objects in the graph. > > + */ > > A bit like my first comment I think this would benefit from an example > what lower/higher mean in this case. I believe a lower object must only > reference/depend on higher objects, correct? Maybe it is too confusing - I was debating using a try and fail approach instead which achieves the same thing with a little different complexity. It seems we may need to do this anyhow for nesting.. Would look like this: /* Destroy the graph from depth first */ while (!xa_empty(&ictx->objects)) { unsigned int destroyed = 0; unsigned long index = 0; xa_for_each (&ictx->objects, index, obj) { /* * Since we are in release elevated users must come from * other objects holding the users. We will eventually * destroy the object that holds this one and the next * pass will progress it. */ if (!refcount_dec_if_one(&obj->users)) continue; destroyed++; xa_erase(&ictx->objects, index); iommufd_object_ops[obj->type].destroy(obj); kfree(obj); } /* Bug related to users refcount */ if (WARN_ON(!destroyed)) break; } kfree(ictx); > > +struct iommufd_object *iommufd_get_object(struct iommufd_ctx *ictx, u32 id, > > + enum iommufd_object_type type) > > +{ > > + struct iommufd_object *obj; > > + > > + xa_lock(&ictx->objects); > > + obj = xa_load(&ictx->objects, id); > > + if (!obj || (type != IOMMUFD_OBJ_ANY && obj->type != type) || > > + !iommufd_lock_obj(obj)) > > Looking at the code it seems iommufd_lock_obj() locks against > destroy_rw_sem and increases the reference count but there is also an > iommufd_put_object_keep_user() which only unlocks the destroy_rw_sem. I > think I personally would benefit from a comment/commit message > explaining the lifecycle. > > There is the below comment in iommufd_object_destroy_user() but I think > it would be better placed near the destroy_rwsem decleration and to > also explain the interaction between the destroy_rwsem and the > reference count. I do prefer it near the destroy because that is the only place that actually requires the property it gives. The code outside this layer shouldn't know about this at all beyond folowing some rules about iommufd_put_object_keep_user(). Lets add a comment there instead: /** * iommufd_put_object_keep_user() - Release part of the refcount on obj * @obj - Object to release * * Objects have two protections to ensure that userspace has a consistent * experience with destruction. Normally objects are locked so that destroy will * block while there are concurrent users, and wait for the object to be * unlocked. * * However, destroy can also be blocked by holding users reference counts on the * objects, in that case destroy will immediately return EBUSY and will not wait * for reference counts to go to zero. * * This function releases the destroy lock and destroy will return EBUSY. * * It should be used in places where the users will be held beyond a single * system call. */ Thanks, Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe via iommu <iommu@lists.linux-foundation.org> To: Niklas Schnelle <schnelle@linux.ibm.com> Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>, Chaitanya Kulkarni <chaitanyak@nvidia.com>, kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>, Jason Wang <jasowang@redhat.com>, Cornelia Huck <cohuck@redhat.com>, iommu@lists.linux-foundation.org, Daniel Jordan <daniel.m.jordan@oracle.com>, Kevin Tian <kevin.tian@intel.com>, Alex Williamson <alex.williamson@redhat.com>, Joao Martins <joao.m.martins@oracle.com>, David Gibson <david@gibson.dropbear.id.au> Subject: Re: [PATCH RFC 03/12] iommufd: File descriptor, context, kconfig and makefiles Date: Tue, 22 Mar 2022 11:50:36 -0300 [thread overview] Message-ID: <20220322145036.GG11336@nvidia.com> (raw) In-Reply-To: <5f1e2f85e45d7cc5c7cade7042a681186d3d7bd3.camel@linux.ibm.com> On Tue, Mar 22, 2022 at 03:18:51PM +0100, Niklas Schnelle wrote: > On Fri, 2022-03-18 at 14:27 -0300, Jason Gunthorpe wrote: > > This is the basic infrastructure of a new miscdevice to hold the iommufd > > IOCTL API. > > > > It provides: > > - A miscdevice to create file descriptors to run the IOCTL interface over > > > > - A table based ioctl dispatch and centralized extendable pre-validation > > step > > > > - An xarray mapping user ID's to kernel objects. The design has multiple > > inter-related objects held within in a single IOMMUFD fd > > > > - A simple usage count to build a graph of object relations and protect > > against hostile userspace racing ioctls > > For me at this point it seems hard to grok what this "graph of object > relations" is about. Maybe an example would help? I'm assuming this is > about e.g. the DEVICE -depends-on-> HW_PAGETABLE -depends-on-> IOAS so > the arrows in the picture of PATCH 02? Yes, it is basically standard reference relations, think 'kref'. Object A referenced B because A has a pointer to B in its struct. Therefore B cannot be destroyed before A without creating a dangling reference. > Or is it the other way around > and the IOAS -depends-on-> HW_PAGETABLE because it's about which > references which? From the rest of the patch I seem to understand that > this mostly establishes the order of destruction. So is HW_PAGETABLE > destroyed before the IOAS because a HW_PAGETABLE must never reference > an invalid/destoryed IOAS or is it the other way arund because the IOAS > has a reference to the HW_PAGETABLES in it? I'd guess the former but > I'm a bit confused still. Yes HW_PAGETABLE is first because it is responsible to remove the iommu_domain from the IOAS and the IOAS cannot be destroyed with iommu_domains in it. > > +/* > > + * The objects for an acyclic graph through the users refcount. This enum must > > + * be sorted by type depth first so that destruction completes lower objects and > > + * releases the users refcount before reaching higher objects in the graph. > > + */ > > A bit like my first comment I think this would benefit from an example > what lower/higher mean in this case. I believe a lower object must only > reference/depend on higher objects, correct? Maybe it is too confusing - I was debating using a try and fail approach instead which achieves the same thing with a little different complexity. It seems we may need to do this anyhow for nesting.. Would look like this: /* Destroy the graph from depth first */ while (!xa_empty(&ictx->objects)) { unsigned int destroyed = 0; unsigned long index = 0; xa_for_each (&ictx->objects, index, obj) { /* * Since we are in release elevated users must come from * other objects holding the users. We will eventually * destroy the object that holds this one and the next * pass will progress it. */ if (!refcount_dec_if_one(&obj->users)) continue; destroyed++; xa_erase(&ictx->objects, index); iommufd_object_ops[obj->type].destroy(obj); kfree(obj); } /* Bug related to users refcount */ if (WARN_ON(!destroyed)) break; } kfree(ictx); > > +struct iommufd_object *iommufd_get_object(struct iommufd_ctx *ictx, u32 id, > > + enum iommufd_object_type type) > > +{ > > + struct iommufd_object *obj; > > + > > + xa_lock(&ictx->objects); > > + obj = xa_load(&ictx->objects, id); > > + if (!obj || (type != IOMMUFD_OBJ_ANY && obj->type != type) || > > + !iommufd_lock_obj(obj)) > > Looking at the code it seems iommufd_lock_obj() locks against > destroy_rw_sem and increases the reference count but there is also an > iommufd_put_object_keep_user() which only unlocks the destroy_rw_sem. I > think I personally would benefit from a comment/commit message > explaining the lifecycle. > > There is the below comment in iommufd_object_destroy_user() but I think > it would be better placed near the destroy_rwsem decleration and to > also explain the interaction between the destroy_rwsem and the > reference count. I do prefer it near the destroy because that is the only place that actually requires the property it gives. The code outside this layer shouldn't know about this at all beyond folowing some rules about iommufd_put_object_keep_user(). Lets add a comment there instead: /** * iommufd_put_object_keep_user() - Release part of the refcount on obj * @obj - Object to release * * Objects have two protections to ensure that userspace has a consistent * experience with destruction. Normally objects are locked so that destroy will * block while there are concurrent users, and wait for the object to be * unlocked. * * However, destroy can also be blocked by holding users reference counts on the * objects, in that case destroy will immediately return EBUSY and will not wait * for reference counts to go to zero. * * This function releases the destroy lock and destroy will return EBUSY. * * It should be used in places where the users will be held beyond a single * system call. */ Thanks, Jason _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2022-03-22 14:50 UTC|newest] Thread overview: 244+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-18 17:27 [PATCH RFC 00/12] IOMMUFD Generic interface Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-18 17:27 ` [PATCH RFC 01/12] interval-tree: Add a utility to iterate over spans in an interval tree Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-18 17:27 ` [PATCH RFC 02/12] iommufd: Overview documentation Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-18 17:27 ` [PATCH RFC 03/12] iommufd: File descriptor, context, kconfig and makefiles Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-22 14:18 ` Niklas Schnelle 2022-03-22 14:18 ` Niklas Schnelle 2022-03-22 14:50 ` Jason Gunthorpe [this message] 2022-03-22 14:50 ` Jason Gunthorpe via iommu 2022-03-18 17:27 ` [PATCH RFC 04/12] kernel/user: Allow user::locked_vm to be usable for iommufd Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-22 14:28 ` Niklas Schnelle 2022-03-22 14:28 ` Niklas Schnelle 2022-03-22 14:57 ` Jason Gunthorpe 2022-03-22 14:57 ` Jason Gunthorpe via iommu 2022-03-22 15:29 ` Alex Williamson 2022-03-22 15:29 ` Alex Williamson 2022-03-22 16:15 ` Jason Gunthorpe 2022-03-22 16:15 ` Jason Gunthorpe via iommu 2022-03-24 2:11 ` Tian, Kevin 2022-03-24 2:11 ` Tian, Kevin 2022-03-24 2:27 ` Jason Wang 2022-03-24 2:27 ` Jason Wang 2022-03-24 2:42 ` Tian, Kevin 2022-03-24 2:42 ` Tian, Kevin 2022-03-24 2:57 ` Jason Wang 2022-03-24 2:57 ` Jason Wang 2022-03-24 3:15 ` Tian, Kevin 2022-03-24 3:15 ` Tian, Kevin 2022-03-24 3:50 ` Jason Wang 2022-03-24 3:50 ` Jason Wang 2022-03-24 4:29 ` Tian, Kevin 2022-03-24 4:29 ` Tian, Kevin 2022-03-24 11:46 ` Jason Gunthorpe 2022-03-24 11:46 ` Jason Gunthorpe via iommu 2022-03-28 1:53 ` Jason Wang 2022-03-28 1:53 ` Jason Wang 2022-03-28 12:22 ` Jason Gunthorpe 2022-03-28 12:22 ` Jason Gunthorpe via iommu 2022-03-29 4:59 ` Jason Wang 2022-03-29 4:59 ` Jason Wang 2022-03-29 11:46 ` Jason Gunthorpe 2022-03-29 11:46 ` Jason Gunthorpe via iommu 2022-03-28 13:14 ` Sean Mooney 2022-03-28 13:14 ` Sean Mooney 2022-03-28 14:27 ` Jason Gunthorpe via iommu 2022-03-28 14:27 ` Jason Gunthorpe 2022-03-24 20:40 ` Alex Williamson 2022-03-24 20:40 ` Alex Williamson 2022-03-24 22:27 ` Jason Gunthorpe 2022-03-24 22:27 ` Jason Gunthorpe via iommu 2022-03-24 22:41 ` Alex Williamson 2022-03-24 22:41 ` Alex Williamson 2022-03-22 16:31 ` Niklas Schnelle 2022-03-22 16:31 ` Niklas Schnelle 2022-03-22 16:41 ` Jason Gunthorpe via iommu 2022-03-22 16:41 ` Jason Gunthorpe 2022-03-18 17:27 ` [PATCH RFC 05/12] iommufd: PFN handling for iopt_pages Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-23 15:37 ` Niklas Schnelle 2022-03-23 15:37 ` Niklas Schnelle 2022-03-23 16:09 ` Jason Gunthorpe 2022-03-23 16:09 ` Jason Gunthorpe via iommu 2022-03-18 17:27 ` [PATCH RFC 06/12] iommufd: Algorithms for PFN storage Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-18 17:27 ` [PATCH RFC 07/12] iommufd: Data structure to provide IOVA to PFN mapping Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-22 22:15 ` Alex Williamson 2022-03-22 22:15 ` Alex Williamson 2022-03-23 18:15 ` Jason Gunthorpe 2022-03-23 18:15 ` Jason Gunthorpe via iommu 2022-03-24 3:09 ` Tian, Kevin 2022-03-24 3:09 ` Tian, Kevin 2022-03-24 12:46 ` Jason Gunthorpe 2022-03-24 12:46 ` Jason Gunthorpe via iommu 2022-03-25 13:34 ` zhangfei.gao 2022-03-25 13:34 ` zhangfei.gao 2022-03-25 17:19 ` Jason Gunthorpe via iommu 2022-03-25 17:19 ` Jason Gunthorpe 2022-04-13 14:02 ` Yi Liu 2022-04-13 14:02 ` Yi Liu 2022-04-13 14:36 ` Jason Gunthorpe 2022-04-13 14:36 ` Jason Gunthorpe via iommu 2022-04-13 14:49 ` Yi Liu 2022-04-13 14:49 ` Yi Liu 2022-04-17 14:56 ` Yi Liu 2022-04-17 14:56 ` Yi Liu 2022-04-18 10:47 ` Yi Liu 2022-04-18 10:47 ` Yi Liu 2022-03-18 17:27 ` [PATCH RFC 08/12] iommufd: IOCTLs for the io_pagetable Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-23 19:10 ` Alex Williamson 2022-03-23 19:10 ` Alex Williamson 2022-03-23 19:34 ` Jason Gunthorpe 2022-03-23 19:34 ` Jason Gunthorpe via iommu 2022-03-23 20:04 ` Alex Williamson 2022-03-23 20:04 ` Alex Williamson 2022-03-23 20:34 ` Jason Gunthorpe via iommu 2022-03-23 20:34 ` Jason Gunthorpe 2022-03-23 22:54 ` Jason Gunthorpe 2022-03-23 22:54 ` Jason Gunthorpe via iommu 2022-03-24 7:25 ` Tian, Kevin 2022-03-24 7:25 ` Tian, Kevin 2022-03-24 13:46 ` Jason Gunthorpe via iommu 2022-03-24 13:46 ` Jason Gunthorpe 2022-03-25 2:15 ` Tian, Kevin 2022-03-25 2:15 ` Tian, Kevin 2022-03-27 2:32 ` Tian, Kevin 2022-03-27 2:32 ` Tian, Kevin 2022-03-27 14:28 ` Jason Gunthorpe 2022-03-27 14:28 ` Jason Gunthorpe via iommu 2022-03-28 17:17 ` Alex Williamson 2022-03-28 17:17 ` Alex Williamson 2022-03-28 18:57 ` Jason Gunthorpe 2022-03-28 18:57 ` Jason Gunthorpe via iommu 2022-03-28 19:47 ` Jason Gunthorpe via iommu 2022-03-28 19:47 ` Jason Gunthorpe 2022-03-28 21:26 ` Alex Williamson 2022-03-28 21:26 ` Alex Williamson 2022-03-24 6:46 ` Tian, Kevin 2022-03-24 6:46 ` Tian, Kevin 2022-03-30 13:35 ` Yi Liu 2022-03-30 13:35 ` Yi Liu 2022-03-31 12:59 ` Jason Gunthorpe via iommu 2022-03-31 12:59 ` Jason Gunthorpe 2022-04-01 13:30 ` Yi Liu 2022-04-01 13:30 ` Yi Liu 2022-03-31 4:36 ` David Gibson 2022-03-31 4:36 ` David Gibson 2022-03-31 5:41 ` Tian, Kevin 2022-03-31 5:41 ` Tian, Kevin 2022-03-31 12:58 ` Jason Gunthorpe via iommu 2022-03-31 12:58 ` Jason Gunthorpe 2022-04-28 5:58 ` David Gibson 2022-04-28 5:58 ` David Gibson 2022-04-28 14:22 ` Jason Gunthorpe 2022-04-28 14:22 ` Jason Gunthorpe via iommu 2022-04-29 6:00 ` David Gibson 2022-04-29 6:00 ` David Gibson 2022-04-29 12:54 ` Jason Gunthorpe 2022-04-29 12:54 ` Jason Gunthorpe via iommu 2022-04-30 14:44 ` David Gibson 2022-04-30 14:44 ` David Gibson 2022-03-18 17:27 ` [PATCH RFC 09/12] iommufd: Add a HW pagetable object Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-18 17:27 ` [PATCH RFC 10/12] iommufd: Add kAPI toward external drivers Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-23 18:10 ` Alex Williamson 2022-03-23 18:10 ` Alex Williamson 2022-03-23 18:15 ` Jason Gunthorpe 2022-03-23 18:15 ` Jason Gunthorpe via iommu 2022-05-11 12:54 ` Yi Liu 2022-05-11 12:54 ` Yi Liu 2022-05-19 9:45 ` Yi Liu 2022-05-19 9:45 ` Yi Liu 2022-05-19 12:35 ` Jason Gunthorpe 2022-05-19 12:35 ` Jason Gunthorpe via iommu 2022-03-18 17:27 ` [PATCH RFC 11/12] iommufd: vfio container FD ioctl compatibility Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-03-23 22:51 ` Alex Williamson 2022-03-23 22:51 ` Alex Williamson 2022-03-24 0:33 ` Jason Gunthorpe 2022-03-24 0:33 ` Jason Gunthorpe via iommu 2022-03-24 8:13 ` Eric Auger 2022-03-24 8:13 ` Eric Auger 2022-03-24 22:04 ` Alex Williamson 2022-03-24 22:04 ` Alex Williamson 2022-03-24 23:11 ` Jason Gunthorpe 2022-03-24 23:11 ` Jason Gunthorpe via iommu 2022-03-25 3:10 ` Tian, Kevin 2022-03-25 3:10 ` Tian, Kevin 2022-03-25 11:24 ` Joao Martins 2022-03-25 11:24 ` Joao Martins 2022-04-28 14:53 ` David Gibson 2022-04-28 14:53 ` David Gibson 2022-04-28 15:10 ` Jason Gunthorpe 2022-04-28 15:10 ` Jason Gunthorpe via iommu 2022-04-29 1:21 ` Tian, Kevin 2022-04-29 1:21 ` Tian, Kevin 2022-04-29 6:22 ` David Gibson 2022-04-29 6:22 ` David Gibson 2022-04-29 12:50 ` Jason Gunthorpe 2022-04-29 12:50 ` Jason Gunthorpe via iommu 2022-05-02 4:10 ` David Gibson 2022-05-02 4:10 ` David Gibson 2022-04-29 6:20 ` David Gibson 2022-04-29 6:20 ` David Gibson 2022-04-29 12:48 ` Jason Gunthorpe 2022-04-29 12:48 ` Jason Gunthorpe via iommu 2022-05-02 7:30 ` David Gibson 2022-05-02 7:30 ` David Gibson 2022-05-05 19:07 ` Jason Gunthorpe 2022-05-05 19:07 ` Jason Gunthorpe via iommu 2022-05-06 5:25 ` David Gibson 2022-05-06 5:25 ` David Gibson 2022-05-06 10:42 ` Tian, Kevin 2022-05-06 10:42 ` Tian, Kevin 2022-05-09 3:36 ` David Gibson 2022-05-09 3:36 ` David Gibson 2022-05-06 12:48 ` Jason Gunthorpe 2022-05-06 12:48 ` Jason Gunthorpe via iommu 2022-05-09 6:01 ` David Gibson 2022-05-09 6:01 ` David Gibson 2022-05-09 14:00 ` Jason Gunthorpe 2022-05-09 14:00 ` Jason Gunthorpe via iommu 2022-05-10 7:12 ` David Gibson 2022-05-10 7:12 ` David Gibson 2022-05-10 19:00 ` Jason Gunthorpe 2022-05-10 19:00 ` Jason Gunthorpe via iommu 2022-05-11 3:15 ` Tian, Kevin 2022-05-11 3:15 ` Tian, Kevin 2022-05-11 16:32 ` Jason Gunthorpe 2022-05-11 16:32 ` Jason Gunthorpe via iommu 2022-05-11 23:23 ` Tian, Kevin 2022-05-11 23:23 ` Tian, Kevin 2022-05-13 4:35 ` David Gibson 2022-05-13 4:35 ` David Gibson 2022-05-11 4:40 ` David Gibson 2022-05-11 4:40 ` David Gibson 2022-05-11 2:46 ` Tian, Kevin 2022-05-11 2:46 ` Tian, Kevin 2022-05-23 6:02 ` Alexey Kardashevskiy 2022-05-23 6:02 ` Alexey Kardashevskiy 2022-05-24 13:25 ` Jason Gunthorpe 2022-05-24 13:25 ` Jason Gunthorpe via iommu 2022-05-25 1:39 ` David Gibson 2022-05-25 1:39 ` David Gibson 2022-05-25 2:09 ` Alexey Kardashevskiy 2022-05-25 2:09 ` Alexey Kardashevskiy 2022-03-29 9:17 ` Yi Liu 2022-03-29 9:17 ` Yi Liu 2022-03-18 17:27 ` [PATCH RFC 12/12] iommufd: Add a selftest Jason Gunthorpe 2022-03-18 17:27 ` Jason Gunthorpe via iommu 2022-04-12 20:13 ` [PATCH RFC 00/12] IOMMUFD Generic interface Eric Auger 2022-04-12 20:13 ` Eric Auger 2022-04-12 20:22 ` Jason Gunthorpe via iommu 2022-04-12 20:22 ` Jason Gunthorpe 2022-04-12 20:50 ` Eric Auger 2022-04-12 20:50 ` Eric Auger 2022-04-14 10:56 ` Yi Liu 2022-04-14 10:56 ` Yi Liu
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=20220322145036.GG11336@nvidia.com \ --to=jgg@nvidia.com \ --cc=alex.williamson@redhat.com \ --cc=baolu.lu@linux.intel.com \ --cc=chaitanyak@nvidia.com \ --cc=cohuck@redhat.com \ --cc=daniel.m.jordan@oracle.com \ --cc=david@gibson.dropbear.id.au \ --cc=eric.auger@redhat.com \ --cc=iommu@lists.linux-foundation.org \ --cc=jasowang@redhat.com \ --cc=jean-philippe@linaro.org \ --cc=joao.m.martins@oracle.com \ --cc=kevin.tian@intel.com \ --cc=kvm@vger.kernel.org \ --cc=mjrosato@linux.ibm.com \ --cc=mst@redhat.com \ --cc=nicolinc@nvidia.com \ --cc=schnelle@linux.ibm.com \ --cc=shameerali.kolothum.thodi@huawei.com \ --cc=yi.l.liu@intel.com \ --cc=zhukeqian1@huawei.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: linkBe 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.