From: Jonathan Cameron <jonathan.cameron@huawei.com> To: Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: <iommu@lists.linux-foundation.org>, LKML <linux-kernel@vger.kernel.org>, Joerg Roedel <joro@8bytes.org>, David Woodhouse <dwmw2@infradead.org>, "Eric Auger" <eric.auger@redhat.com>, Alex Williamson <alex.williamson@redhat.com>, Jean-Philippe Brucker <jean-philippe.brucker@arm.com>, "Tian, Kevin" <kevin.tian@intel.com>, Raj Ashok <ashok.raj@intel.com>, Andriy Shevchenko <andriy.shevchenko@linux.intel.com> Subject: Re: [PATCH v4 03/22] iommu: Introduce device fault report API Date: Tue, 18 Jun 2019 16:41:58 +0100 [thread overview] Message-ID: <20190618164158.0000489c@huawei.com> (raw) In-Reply-To: <1560087862-57608-4-git-send-email-jacob.jun.pan@linux.intel.com> On Sun, 9 Jun 2019 06:44:03 -0700 Jacob Pan <jacob.jun.pan@linux.intel.com> wrote: > Traditionally, device specific faults are detected and handled within > their own device drivers. When IOMMU is enabled, faults such as DMA > related transactions are detected by IOMMU. There is no generic > reporting mechanism to report faults back to the in-kernel device > driver or the guest OS in case of assigned devices. > > This patch introduces a registration API for device specific fault > handlers. This differs from the existing iommu_set_fault_handler/ > report_iommu_fault infrastructures in several ways: > - it allows to report more sophisticated fault events (both > unrecoverable faults and page request faults) due to the nature > of the iommu_fault struct > - it is device specific and not domain specific. > > The current iommu_report_device_fault() implementation only handles > the "shoot and forget" unrecoverable fault case. Handling of page > request faults or stalled faults will come later. > > Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> > Signed-off-by: Ashok Raj <ashok.raj@intel.com> > Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> > Signed-off-by: Eric Auger <eric.auger@redhat.com> A few nitpicks and minor suggestions inline. > --- > drivers/iommu/iommu.c | 127 +++++++++++++++++++++++++++++++++++++++++++++++++- > include/linux/iommu.h | 33 ++++++++++++- > 2 files changed, 157 insertions(+), 3 deletions(-) > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index 67ee662..7955184 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -644,6 +644,13 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev) > goto err_free_name; > } > > + dev->iommu_param = kzalloc(sizeof(*dev->iommu_param), GFP_KERNEL); > + if (!dev->iommu_param) { > + ret = -ENOMEM; > + goto err_free_name; > + } > + mutex_init(&dev->iommu_param->lock); > + > kobject_get(group->devices_kobj); > > dev->iommu_group = group; > @@ -674,6 +681,7 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev) > mutex_unlock(&group->mutex); > dev->iommu_group = NULL; > kobject_put(group->devices_kobj); > + kfree(dev->iommu_param); > err_free_name: > kfree(device->name); > err_remove_link: > @@ -720,7 +728,7 @@ void iommu_group_remove_device(struct device *dev) > sysfs_remove_link(&dev->kobj, "iommu_group"); > > trace_remove_device_from_group(group->id, dev); > - > + kfree(dev->iommu_param); > kfree(device->name); > kfree(device); > dev->iommu_group = NULL; > @@ -855,6 +863,123 @@ int iommu_group_unregister_notifier(struct iommu_group *group, > EXPORT_SYMBOL_GPL(iommu_group_unregister_notifier); > > /** > + * iommu_register_device_fault_handler() - Register a device fault handler > + * @dev: the device > + * @handler: the fault handler > + * @data: private data passed as argument to the handler > + * > + * When an IOMMU fault event is received, this handler gets called with the > + * fault event and data as argument. > + * > + * Return 0 if the fault handler was installed successfully, or an error. > + */ > +int iommu_register_device_fault_handler(struct device *dev, > + iommu_dev_fault_handler_t handler, > + void *data) > +{ > + struct iommu_param *param = dev->iommu_param; > + int ret = 0; > + > + /* > + * Device iommu_param should have been allocated when device is > + * added to its iommu_group. > + */ > + if (!param) > + return -EINVAL; > + > + mutex_lock(¶m->lock); > + /* Only allow one fault handler registered for each device */ > + if (param->fault_param) { > + ret = -EBUSY; > + goto done_unlock; > + } > + > + get_device(dev); > + param->fault_param = > + kzalloc(sizeof(struct iommu_fault_param), GFP_KERNEL); > + if (!param->fault_param) { > + put_device(dev); > + ret = -ENOMEM; > + goto done_unlock; > + } > + param->fault_param->handler = handler; > + param->fault_param->data = data; > + > +done_unlock: > + mutex_unlock(¶m->lock); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(iommu_register_device_fault_handler); > + > +/** > + * iommu_unregister_device_fault_handler() - Unregister the device fault handler > + * @dev: the device > + * > + * Remove the device fault handler installed with > + * iommu_register_device_fault_handler(). > + * > + * Return 0 on success, or an error. > + */ > +int iommu_unregister_device_fault_handler(struct device *dev) > +{ > + struct iommu_param *param = dev->iommu_param; > + int ret = 0; > + > + if (!param) > + return -EINVAL; > + > + mutex_lock(¶m->lock); > + > + if (!param->fault_param) > + goto unlock; > + > + kfree(param->fault_param); > + param->fault_param = NULL; > + put_device(dev); > +unlock: > + mutex_unlock(¶m->lock); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(iommu_unregister_device_fault_handler); > + One blank line probably enough.. (my personal favourite stylistic nitpick ;) > + > +/** > + * iommu_report_device_fault() - Report fault event to device > + * @dev: the device > + * @evt: fault event data > + * > + * Called by IOMMU drivers when a fault is detected, typically in a threaded IRQ > + * handler. What constraints does that put on it? We probably don't care about the fact it is in a threaded irq as such, rather something that is true as a result of that? > + * > + * Return 0 on success, or an error. > + */ > +int iommu_report_device_fault(struct device *dev, struct iommu_fault_event *evt) > +{ > + struct iommu_param *param = dev->iommu_param; > + struct iommu_fault_param *fparam; > + int ret = 0; > + > + /* iommu_param is allocated when device is added to group */ > + if (!param || !evt) > + return -EINVAL; > + > + /* we only report device fault if there is a handler registered */ > + mutex_lock(¶m->lock); > + fparam = param->fault_param; > + if (!fparam || !fparam->handler) { > + ret = -EINVAL; > + goto done_unlock; > + } > + ret = fparam->handler(evt, fparam->data); > +done_unlock: > + mutex_unlock(¶m->lock); > + return ret; > +} > +EXPORT_SYMBOL_GPL(iommu_report_device_fault); > + > +/** > * iommu_group_id - Return ID for a group > * @group: the group to ID > * > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > index 7890a92..b87b74c 100644 > --- a/include/linux/iommu.h > +++ b/include/linux/iommu.h > @@ -322,9 +322,9 @@ struct iommu_fault_event { > > /** > * struct iommu_fault_param - per-device IOMMU fault data > - * @dev_fault_handler: Callback function to handle IOMMU faults at device level > - * @data: handler private data > * > + * @handler: Callback function to handle IOMMU faults at device level This should be in the previous patch, not this one. > + * @data: handler private data > */ > struct iommu_fault_param { > iommu_dev_fault_handler_t handler; > @@ -341,6 +341,7 @@ struct iommu_fault_param { > * struct iommu_fwspec *iommu_fwspec; > */ > struct iommu_param { > + struct mutex lock; Structure has kernel doc so this should be added to that. > struct iommu_fault_param *fault_param; > }; > > @@ -433,6 +434,15 @@ extern int iommu_group_register_notifier(struct iommu_group *group, > struct notifier_block *nb); > extern int iommu_group_unregister_notifier(struct iommu_group *group, > struct notifier_block *nb); > +extern int iommu_register_device_fault_handler(struct device *dev, > + iommu_dev_fault_handler_t handler, > + void *data); > + > +extern int iommu_unregister_device_fault_handler(struct device *dev); > + > +extern int iommu_report_device_fault(struct device *dev, > + struct iommu_fault_event *evt); > + > extern int iommu_group_id(struct iommu_group *group); > extern struct iommu_group *iommu_group_get_for_dev(struct device *dev); > extern struct iommu_domain *iommu_group_default_domain(struct iommu_group *); > @@ -741,6 +751,25 @@ static inline int iommu_group_unregister_notifier(struct iommu_group *group, > return 0; > } > > +static inline > +int iommu_register_device_fault_handler(struct device *dev, > + iommu_dev_fault_handler_t handler, > + void *data) > +{ > + return -ENODEV; > +} > + > +static inline int iommu_unregister_device_fault_handler(struct device *dev) > +{ > + return 0; > +} > + > +static inline > +int iommu_report_device_fault(struct device *dev, struct iommu_fault_event *evt) > +{ > + return -ENODEV; > +} > + > static inline int iommu_group_id(struct iommu_group *group) > { > return -ENODEV;
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <jonathan.cameron@huawei.com> To: Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: "Tian, Kevin" <kevin.tian@intel.com>, Raj Ashok <ashok.raj@intel.com>, Jean-Philippe Brucker <jean-philippe.brucker@arm.com>, iommu@lists.linux-foundation.org, LKML <linux-kernel@vger.kernel.org>, Alex Williamson <alex.williamson@redhat.com>, Andriy Shevchenko <andriy.shevchenko@linux.intel.com>, David Woodhouse <dwmw2@infradead.org> Subject: Re: [PATCH v4 03/22] iommu: Introduce device fault report API Date: Tue, 18 Jun 2019 16:41:58 +0100 [thread overview] Message-ID: <20190618164158.0000489c@huawei.com> (raw) In-Reply-To: <1560087862-57608-4-git-send-email-jacob.jun.pan@linux.intel.com> On Sun, 9 Jun 2019 06:44:03 -0700 Jacob Pan <jacob.jun.pan@linux.intel.com> wrote: > Traditionally, device specific faults are detected and handled within > their own device drivers. When IOMMU is enabled, faults such as DMA > related transactions are detected by IOMMU. There is no generic > reporting mechanism to report faults back to the in-kernel device > driver or the guest OS in case of assigned devices. > > This patch introduces a registration API for device specific fault > handlers. This differs from the existing iommu_set_fault_handler/ > report_iommu_fault infrastructures in several ways: > - it allows to report more sophisticated fault events (both > unrecoverable faults and page request faults) due to the nature > of the iommu_fault struct > - it is device specific and not domain specific. > > The current iommu_report_device_fault() implementation only handles > the "shoot and forget" unrecoverable fault case. Handling of page > request faults or stalled faults will come later. > > Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> > Signed-off-by: Ashok Raj <ashok.raj@intel.com> > Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> > Signed-off-by: Eric Auger <eric.auger@redhat.com> A few nitpicks and minor suggestions inline. > --- > drivers/iommu/iommu.c | 127 +++++++++++++++++++++++++++++++++++++++++++++++++- > include/linux/iommu.h | 33 ++++++++++++- > 2 files changed, 157 insertions(+), 3 deletions(-) > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index 67ee662..7955184 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -644,6 +644,13 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev) > goto err_free_name; > } > > + dev->iommu_param = kzalloc(sizeof(*dev->iommu_param), GFP_KERNEL); > + if (!dev->iommu_param) { > + ret = -ENOMEM; > + goto err_free_name; > + } > + mutex_init(&dev->iommu_param->lock); > + > kobject_get(group->devices_kobj); > > dev->iommu_group = group; > @@ -674,6 +681,7 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev) > mutex_unlock(&group->mutex); > dev->iommu_group = NULL; > kobject_put(group->devices_kobj); > + kfree(dev->iommu_param); > err_free_name: > kfree(device->name); > err_remove_link: > @@ -720,7 +728,7 @@ void iommu_group_remove_device(struct device *dev) > sysfs_remove_link(&dev->kobj, "iommu_group"); > > trace_remove_device_from_group(group->id, dev); > - > + kfree(dev->iommu_param); > kfree(device->name); > kfree(device); > dev->iommu_group = NULL; > @@ -855,6 +863,123 @@ int iommu_group_unregister_notifier(struct iommu_group *group, > EXPORT_SYMBOL_GPL(iommu_group_unregister_notifier); > > /** > + * iommu_register_device_fault_handler() - Register a device fault handler > + * @dev: the device > + * @handler: the fault handler > + * @data: private data passed as argument to the handler > + * > + * When an IOMMU fault event is received, this handler gets called with the > + * fault event and data as argument. > + * > + * Return 0 if the fault handler was installed successfully, or an error. > + */ > +int iommu_register_device_fault_handler(struct device *dev, > + iommu_dev_fault_handler_t handler, > + void *data) > +{ > + struct iommu_param *param = dev->iommu_param; > + int ret = 0; > + > + /* > + * Device iommu_param should have been allocated when device is > + * added to its iommu_group. > + */ > + if (!param) > + return -EINVAL; > + > + mutex_lock(¶m->lock); > + /* Only allow one fault handler registered for each device */ > + if (param->fault_param) { > + ret = -EBUSY; > + goto done_unlock; > + } > + > + get_device(dev); > + param->fault_param = > + kzalloc(sizeof(struct iommu_fault_param), GFP_KERNEL); > + if (!param->fault_param) { > + put_device(dev); > + ret = -ENOMEM; > + goto done_unlock; > + } > + param->fault_param->handler = handler; > + param->fault_param->data = data; > + > +done_unlock: > + mutex_unlock(¶m->lock); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(iommu_register_device_fault_handler); > + > +/** > + * iommu_unregister_device_fault_handler() - Unregister the device fault handler > + * @dev: the device > + * > + * Remove the device fault handler installed with > + * iommu_register_device_fault_handler(). > + * > + * Return 0 on success, or an error. > + */ > +int iommu_unregister_device_fault_handler(struct device *dev) > +{ > + struct iommu_param *param = dev->iommu_param; > + int ret = 0; > + > + if (!param) > + return -EINVAL; > + > + mutex_lock(¶m->lock); > + > + if (!param->fault_param) > + goto unlock; > + > + kfree(param->fault_param); > + param->fault_param = NULL; > + put_device(dev); > +unlock: > + mutex_unlock(¶m->lock); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(iommu_unregister_device_fault_handler); > + One blank line probably enough.. (my personal favourite stylistic nitpick ;) > + > +/** > + * iommu_report_device_fault() - Report fault event to device > + * @dev: the device > + * @evt: fault event data > + * > + * Called by IOMMU drivers when a fault is detected, typically in a threaded IRQ > + * handler. What constraints does that put on it? We probably don't care about the fact it is in a threaded irq as such, rather something that is true as a result of that? > + * > + * Return 0 on success, or an error. > + */ > +int iommu_report_device_fault(struct device *dev, struct iommu_fault_event *evt) > +{ > + struct iommu_param *param = dev->iommu_param; > + struct iommu_fault_param *fparam; > + int ret = 0; > + > + /* iommu_param is allocated when device is added to group */ > + if (!param || !evt) > + return -EINVAL; > + > + /* we only report device fault if there is a handler registered */ > + mutex_lock(¶m->lock); > + fparam = param->fault_param; > + if (!fparam || !fparam->handler) { > + ret = -EINVAL; > + goto done_unlock; > + } > + ret = fparam->handler(evt, fparam->data); > +done_unlock: > + mutex_unlock(¶m->lock); > + return ret; > +} > +EXPORT_SYMBOL_GPL(iommu_report_device_fault); > + > +/** > * iommu_group_id - Return ID for a group > * @group: the group to ID > * > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > index 7890a92..b87b74c 100644 > --- a/include/linux/iommu.h > +++ b/include/linux/iommu.h > @@ -322,9 +322,9 @@ struct iommu_fault_event { > > /** > * struct iommu_fault_param - per-device IOMMU fault data > - * @dev_fault_handler: Callback function to handle IOMMU faults at device level > - * @data: handler private data > * > + * @handler: Callback function to handle IOMMU faults at device level This should be in the previous patch, not this one. > + * @data: handler private data > */ > struct iommu_fault_param { > iommu_dev_fault_handler_t handler; > @@ -341,6 +341,7 @@ struct iommu_fault_param { > * struct iommu_fwspec *iommu_fwspec; > */ > struct iommu_param { > + struct mutex lock; Structure has kernel doc so this should be added to that. > struct iommu_fault_param *fault_param; > }; > > @@ -433,6 +434,15 @@ extern int iommu_group_register_notifier(struct iommu_group *group, > struct notifier_block *nb); > extern int iommu_group_unregister_notifier(struct iommu_group *group, > struct notifier_block *nb); > +extern int iommu_register_device_fault_handler(struct device *dev, > + iommu_dev_fault_handler_t handler, > + void *data); > + > +extern int iommu_unregister_device_fault_handler(struct device *dev); > + > +extern int iommu_report_device_fault(struct device *dev, > + struct iommu_fault_event *evt); > + > extern int iommu_group_id(struct iommu_group *group); > extern struct iommu_group *iommu_group_get_for_dev(struct device *dev); > extern struct iommu_domain *iommu_group_default_domain(struct iommu_group *); > @@ -741,6 +751,25 @@ static inline int iommu_group_unregister_notifier(struct iommu_group *group, > return 0; > } > > +static inline > +int iommu_register_device_fault_handler(struct device *dev, > + iommu_dev_fault_handler_t handler, > + void *data) > +{ > + return -ENODEV; > +} > + > +static inline int iommu_unregister_device_fault_handler(struct device *dev) > +{ > + return 0; > +} > + > +static inline > +int iommu_report_device_fault(struct device *dev, struct iommu_fault_event *evt) > +{ > + return -ENODEV; > +} > + > static inline int iommu_group_id(struct iommu_group *group) > { > return -ENODEV; _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-06-19 16:31 UTC|newest] Thread overview: 135+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-09 13:44 [PATCH v4 00/22] Shared virtual address IOMMU and VT-d support Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-09 13:44 ` [PATCH v4 01/22] driver core: Add per device iommu param Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-09 13:44 ` [PATCH v4 02/22] iommu: Introduce device fault data Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-18 15:42 ` Jonathan Cameron 2019-06-18 15:42 ` Jonathan Cameron 2019-06-09 13:44 ` [PATCH v4 03/22] iommu: Introduce device fault report API Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-18 15:41 ` Jonathan Cameron [this message] 2019-06-18 15:41 ` Jonathan Cameron 2019-06-09 13:44 ` [PATCH v4 04/22] iommu: Add recoverable fault reporting Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-18 15:44 ` Jonathan Cameron 2019-06-18 15:44 ` Jonathan Cameron 2019-06-09 13:44 ` [PATCH v4 05/22] iommu: Add a timeout parameter for PRQ response Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-09 13:44 ` [PATCH v4 06/22] trace/iommu: Add sva trace events Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-09 13:44 ` [PATCH v4 07/22] iommu: Use device fault trace event Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-09 13:44 ` [PATCH v4 08/22] iommu: Introduce attach/detach_pasid_table API Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-18 15:41 ` Jonathan Cameron 2019-06-18 15:41 ` Jonathan Cameron 2019-06-24 15:06 ` Auger Eric 2019-06-24 15:06 ` Auger Eric 2019-06-24 15:23 ` Jean-Philippe Brucker 2019-06-24 15:23 ` Jean-Philippe Brucker 2019-06-09 13:44 ` [PATCH v4 09/22] iommu: Introduce cache_invalidate API Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-18 15:41 ` Jonathan Cameron 2019-06-18 15:41 ` Jonathan Cameron 2019-06-09 13:44 ` [PATCH v4 10/22] iommu: Fix compile error without IOMMU_API Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-18 14:10 ` Jonathan Cameron 2019-06-18 14:10 ` Jonathan Cameron 2019-06-24 22:28 ` Jacob Pan 2019-06-24 22:28 ` Jacob Pan 2019-06-09 13:44 ` [PATCH v4 11/22] iommu: Introduce guest PASID bind function Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-18 15:36 ` Jean-Philippe Brucker 2019-06-18 15:36 ` Jean-Philippe Brucker 2019-06-24 22:24 ` Jacob Pan 2019-06-24 22:24 ` Jacob Pan 2019-07-16 16:44 ` Auger Eric 2019-07-16 16:44 ` Auger Eric 2019-08-05 21:02 ` Jacob Pan 2019-08-05 21:02 ` Jacob Pan 2019-08-05 23:13 ` Jacob Pan 2019-08-05 23:13 ` Jacob Pan 2019-06-09 13:44 ` [PATCH v4 12/22] iommu: Add I/O ASID allocator Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-18 16:50 ` Jonathan Cameron 2019-06-18 16:50 ` Jonathan Cameron 2019-06-25 18:55 ` Jacob Pan 2019-06-25 18:55 ` Jacob Pan 2019-06-09 13:44 ` [PATCH v4 13/22] iommu/vt-d: Enlightened PASID allocation Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-07-16 9:29 ` Auger Eric 2019-07-16 9:29 ` Auger Eric 2019-08-13 16:57 ` Jacob Pan 2019-08-13 16:57 ` Jacob Pan 2019-06-09 13:44 ` [PATCH v4 14/22] iommu/vt-d: Add custom allocator for IOASID Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-07-16 9:30 ` Auger Eric 2019-07-16 9:30 ` Auger Eric 2019-08-05 20:02 ` Jacob Pan 2019-08-05 20:02 ` Jacob Pan 2019-06-09 13:44 ` [PATCH v4 15/22] iommu/vt-d: Replace Intel specific PASID allocator with IOASID Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-18 15:57 ` Jonathan Cameron 2019-06-18 15:57 ` Jonathan Cameron 2019-06-24 21:36 ` Jacob Pan 2019-06-24 21:36 ` Jacob Pan 2019-06-27 1:53 ` Lu Baolu 2019-06-27 1:53 ` Lu Baolu 2019-06-27 15:40 ` Jacob Pan 2019-06-27 15:40 ` Jacob Pan 2019-06-09 13:44 ` [PATCH v4 16/22] iommu/vt-d: Move domain helper to header Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-07-16 9:33 ` Auger Eric 2019-07-16 9:33 ` Auger Eric 2019-06-09 13:44 ` [PATCH v4 17/22] iommu/vt-d: Avoid duplicated code for PASID setup Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-18 16:03 ` Jonathan Cameron 2019-06-18 16:03 ` Jonathan Cameron 2019-06-24 23:44 ` Jacob Pan 2019-06-24 23:44 ` Jacob Pan 2019-07-16 9:52 ` Auger Eric 2019-07-16 9:52 ` Auger Eric 2019-06-09 13:44 ` [PATCH v4 18/22] iommu/vt-d: Add nested translation helper function Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-09 13:44 ` [PATCH v4 19/22] iommu/vt-d: Clean up for SVM device list Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-18 16:42 ` Jonathan Cameron 2019-06-18 16:42 ` Jonathan Cameron 2019-06-24 23:59 ` Jacob Pan 2019-06-24 23:59 ` Jacob Pan 2019-06-09 13:44 ` [PATCH v4 20/22] iommu/vt-d: Add bind guest PASID support Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-06-18 16:44 ` Jonathan Cameron 2019-06-18 16:44 ` Jonathan Cameron 2019-06-24 22:41 ` Jacob Pan 2019-06-24 22:41 ` Jacob Pan 2019-06-27 2:50 ` Lu Baolu 2019-06-27 2:50 ` Lu Baolu 2019-06-27 20:22 ` Jacob Pan 2019-06-27 20:22 ` Jacob Pan 2019-07-05 2:21 ` Lu Baolu 2019-07-05 2:21 ` Lu Baolu 2019-08-14 17:20 ` Jacob Pan 2019-08-14 17:20 ` Jacob Pan 2019-07-16 16:45 ` Auger Eric 2019-07-16 16:45 ` Auger Eric 2019-07-16 17:04 ` Raj, Ashok 2019-07-16 17:04 ` Raj, Ashok 2019-07-18 7:47 ` Auger Eric 2019-07-18 7:47 ` Auger Eric 2019-06-09 13:44 ` [PATCH v4 21/22] iommu/vt-d: Support flushing more translation cache types Jacob Pan 2019-06-09 13:44 ` Jacob Pan 2019-07-18 8:35 ` Auger Eric 2019-07-18 8:35 ` Auger Eric 2019-08-14 20:17 ` Jacob Pan 2019-08-14 20:17 ` Jacob Pan 2019-06-09 13:44 ` [PATCH v4 22/22] iommu/vt-d: Add svm/sva invalidate function Jacob Pan 2019-06-09 13:44 ` Jacob Pan -- strict thread matches above, loose matches on Subject: below -- 2019-02-18 13:54 [PATCH v4 00/22] SMMUv3 Nested Stage Setup Eric Auger 2019-02-18 13:54 ` [PATCH v4 03/22] iommu: introduce device fault report API Eric Auger 2019-02-18 13:54 ` Eric Auger 2019-03-05 15:03 ` Jean-Philippe Brucker 2019-03-06 23:46 ` Jacob Pan 2019-03-07 11:42 ` Jean-Philippe Brucker 2019-03-07 11:42 ` Jean-Philippe Brucker 2019-03-07 11:42 ` Jean-Philippe Brucker
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=20190618164158.0000489c@huawei.com \ --to=jonathan.cameron@huawei.com \ --cc=alex.williamson@redhat.com \ --cc=andriy.shevchenko@linux.intel.com \ --cc=ashok.raj@intel.com \ --cc=dwmw2@infradead.org \ --cc=eric.auger@redhat.com \ --cc=iommu@lists.linux-foundation.org \ --cc=jacob.jun.pan@linux.intel.com \ --cc=jean-philippe.brucker@arm.com \ --cc=joro@8bytes.org \ --cc=kevin.tian@intel.com \ --cc=linux-kernel@vger.kernel.org \ /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.