From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: devicetree@vger.kernel.org, kevin.tian@intel.com, jgg@ziepe.ca,
linux-pci@vger.kernel.org, robin.murphy@arm.com,
fenghua.yu@intel.com, hch@infradead.org, linux-mm@kvack.org,
iommu@lists.linux-foundation.org, zhangfei.gao@linaro.org,
catalin.marinas@arm.com, felix.kuehling@amd.com, will@kernel.org,
christian.koenig@amd.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 04/25] iommu: Add a page fault handler
Date: Mon, 4 May 2020 18:22:42 +0200 [thread overview]
Message-ID: <20200504162242.GF170104@myrica> (raw)
In-Reply-To: <9a8ec004-0a9c-d772-8e7a-f839002a40b5@linux.intel.com>
On Sun, May 03, 2020 at 01:49:01PM +0800, Lu Baolu wrote:
> > +static void iopf_handle_group(struct work_struct *work)
> > +{
> > + struct iopf_group *group;
> > + struct iopf_fault *iopf, *next;
> > + enum iommu_page_response_code status = IOMMU_PAGE_RESP_SUCCESS;
> > +
> > + group = container_of(work, struct iopf_group, work);
> > +
> > + list_for_each_entry_safe(iopf, next, &group->faults, head) {
> > + /*
> > + * For the moment, errors are sticky: don't handle subsequent
> > + * faults in the group if there is an error.
> > + */
> > + if (status == IOMMU_PAGE_RESP_SUCCESS)
> > + status = iopf_handle_single(iopf);
> > +
> > + if (!(iopf->fault.prm.flags &
> > + IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE))
> > + kfree(iopf);
>
> The iopf is freed,but not removed from the list. This will cause wild
> pointer in code.
We free the list with the group below, so this one is fine.
>
> > + }
> > +
> > + iopf_complete_group(group->dev, &group->last_fault, status);
> > + kfree(group);
> > +}
> > +
>
> [...]
>
> > +/**
> > + * iopf_queue_flush_dev - Ensure that all queued faults have been processed
> > + * @dev: the endpoint whose faults need to be flushed.
> > + * @pasid: the PASID affected by this flush
> > + *
> > + * The IOMMU driver calls this before releasing a PASID, to ensure that all
> > + * pending faults for this PASID have been handled, and won't hit the address
> > + * space of the next process that uses this PASID. The driver must make sure
> > + * that no new fault is added to the queue. In particular it must flush its
> > + * low-level queue before calling this function.
> > + *
> > + * Return: 0 on success and <0 on error.
> > + */
> > +int iopf_queue_flush_dev(struct device *dev, int pasid)
> > +{
> > + int ret = 0;
> > + struct iopf_device_param *iopf_param;
> > + struct dev_iommu *param = dev->iommu;
> > +
> > + if (!param)
> > + return -ENODEV;
> > +
> > + mutex_lock(¶m->lock);
> > + iopf_param = param->iopf_param;
> > + if (iopf_param)
> > + flush_workqueue(iopf_param->queue->wq);
>
> There may be other pasid iopf in the workqueue. Flush all tasks in
> the workqueue will hurt other pasids. I might lose any context.
Granted this isn't optimal because we don't take the PASID argument into
account (I think I'll remove it, don't know how to use it). But I don't
think it affects other PASIDs, because all flush_workqueue() does is wait
until all faults currently in the worqueue are processed. So it only
blocks the current thread, but nothing is lost.
>
> > + else
> > + ret = -ENODEV;
> > + mutex_unlock(¶m->lock);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(iopf_queue_flush_dev);
> > +
> > +/**
> > + * iopf_queue_discard_partial - Remove all pending partial fault
> > + * @queue: the queue whose partial faults need to be discarded
> > + *
> > + * When the hardware queue overflows, last page faults in a group may have been
> > + * lost and the IOMMU driver calls this to discard all partial faults. The
> > + * driver shouldn't be adding new faults to this queue concurrently.
> > + *
> > + * Return: 0 on success and <0 on error.
> > + */
> > +int iopf_queue_discard_partial(struct iopf_queue *queue)
> > +{
> > + struct iopf_fault *iopf, *next;
> > + struct iopf_device_param *iopf_param;
> > +
> > + if (!queue)
> > + return -EINVAL;
> > +
> > + mutex_lock(&queue->lock);
> > + list_for_each_entry(iopf_param, &queue->devices, queue_list) {
> > + list_for_each_entry_safe(iopf, next, &iopf_param->partial, head)
> > + kfree(iopf);
>
> iopf is freed but not removed from the list.
Ouch yes this is wrong, will fix.
>
> > + }
> > + mutex_unlock(&queue->lock);
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(iopf_queue_discard_partial);
> > +
> > +/**
> > + * iopf_queue_add_device - Add producer to the fault queue
> > + * @queue: IOPF queue
> > + * @dev: device to add
> > + *
> > + * Return: 0 on success and <0 on error.
> > + */
> > +int iopf_queue_add_device(struct iopf_queue *queue, struct device *dev)
> > +{
> > + int ret = -EBUSY;
> > + struct iopf_device_param *iopf_param;
> > + struct dev_iommu *param = dev->iommu;
> > +
> > + if (!param)
> > + return -ENODEV;
> > +
> > + iopf_param = kzalloc(sizeof(*iopf_param), GFP_KERNEL);
> > + if (!iopf_param)
> > + return -ENOMEM;
> > +
> > + INIT_LIST_HEAD(&iopf_param->partial);
> > + iopf_param->queue = queue;
> > + iopf_param->dev = dev;
> > +
> > + mutex_lock(&queue->lock);
> > + mutex_lock(¶m->lock);
> > + if (!param->iopf_param) {
> > + list_add(&iopf_param->queue_list, &queue->devices);
> > + param->iopf_param = iopf_param;
> > + ret = 0;
> > + }
> > + mutex_unlock(¶m->lock);
> > + mutex_unlock(&queue->lock);
> > +
> > + if (ret)
> > + kfree(iopf_param);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(iopf_queue_add_device);
> > +
> > +/**
> > + * iopf_queue_remove_device - Remove producer from fault queue
> > + * @queue: IOPF queue
> > + * @dev: device to remove
> > + *
> > + * Caller makes sure that no more faults are reported for this device.
> > + *
> > + * Return: 0 on success and <0 on error.
> > + */
> > +int iopf_queue_remove_device(struct iopf_queue *queue, struct device *dev)
> > +{
> > + int ret = 0;
> > + struct iopf_fault *iopf, *next;
> > + struct iopf_device_param *iopf_param;
> > + struct dev_iommu *param = dev->iommu;
> > +
> > + if (!param || !queue)
> > + return -EINVAL;
> > +
> > + mutex_lock(&queue->lock);
> > + mutex_lock(¶m->lock);
> > + iopf_param = param->iopf_param;
> > + if (iopf_param && iopf_param->queue == queue) {
> > + list_del(&iopf_param->queue_list);
> > + param->iopf_param = NULL;
> > + } else {
> > + ret = -EINVAL;
> > + }
> > + mutex_unlock(¶m->lock);
> > + mutex_unlock(&queue->lock);
> > + if (ret)
> > + return ret;
> > +
> > + /* Just in case some faults are still stuck */
> > + list_for_each_entry_safe(iopf, next, &iopf_param->partial, head)
> > + kfree(iopf);
>
> The same here.
Here is fine, we free the iopf_param below
Thanks,
Jean
>
> > +
> > + kfree(iopf_param);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(iopf_queue_remove_device);
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: iommu@lists.linux-foundation.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
linux-mm@kvack.org, joro@8bytes.org, catalin.marinas@arm.com,
will@kernel.org, robin.murphy@arm.com, kevin.tian@intel.com,
Jonathan.Cameron@huawei.com, jacob.jun.pan@linux.intel.com,
christian.koenig@amd.com, felix.kuehling@amd.com,
zhangfei.gao@linaro.org, jgg@ziepe.ca, xuzaibo@huawei.com,
fenghua.yu@intel.com, hch@infradead.org
Subject: Re: [PATCH v6 04/25] iommu: Add a page fault handler
Date: Mon, 4 May 2020 18:22:42 +0200 [thread overview]
Message-ID: <20200504162242.GF170104@myrica> (raw)
In-Reply-To: <9a8ec004-0a9c-d772-8e7a-f839002a40b5@linux.intel.com>
On Sun, May 03, 2020 at 01:49:01PM +0800, Lu Baolu wrote:
> > +static void iopf_handle_group(struct work_struct *work)
> > +{
> > + struct iopf_group *group;
> > + struct iopf_fault *iopf, *next;
> > + enum iommu_page_response_code status = IOMMU_PAGE_RESP_SUCCESS;
> > +
> > + group = container_of(work, struct iopf_group, work);
> > +
> > + list_for_each_entry_safe(iopf, next, &group->faults, head) {
> > + /*
> > + * For the moment, errors are sticky: don't handle subsequent
> > + * faults in the group if there is an error.
> > + */
> > + if (status == IOMMU_PAGE_RESP_SUCCESS)
> > + status = iopf_handle_single(iopf);
> > +
> > + if (!(iopf->fault.prm.flags &
> > + IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE))
> > + kfree(iopf);
>
> The iopf is freed,but not removed from the list. This will cause wild
> pointer in code.
We free the list with the group below, so this one is fine.
>
> > + }
> > +
> > + iopf_complete_group(group->dev, &group->last_fault, status);
> > + kfree(group);
> > +}
> > +
>
> [...]
>
> > +/**
> > + * iopf_queue_flush_dev - Ensure that all queued faults have been processed
> > + * @dev: the endpoint whose faults need to be flushed.
> > + * @pasid: the PASID affected by this flush
> > + *
> > + * The IOMMU driver calls this before releasing a PASID, to ensure that all
> > + * pending faults for this PASID have been handled, and won't hit the address
> > + * space of the next process that uses this PASID. The driver must make sure
> > + * that no new fault is added to the queue. In particular it must flush its
> > + * low-level queue before calling this function.
> > + *
> > + * Return: 0 on success and <0 on error.
> > + */
> > +int iopf_queue_flush_dev(struct device *dev, int pasid)
> > +{
> > + int ret = 0;
> > + struct iopf_device_param *iopf_param;
> > + struct dev_iommu *param = dev->iommu;
> > +
> > + if (!param)
> > + return -ENODEV;
> > +
> > + mutex_lock(¶m->lock);
> > + iopf_param = param->iopf_param;
> > + if (iopf_param)
> > + flush_workqueue(iopf_param->queue->wq);
>
> There may be other pasid iopf in the workqueue. Flush all tasks in
> the workqueue will hurt other pasids. I might lose any context.
Granted this isn't optimal because we don't take the PASID argument into
account (I think I'll remove it, don't know how to use it). But I don't
think it affects other PASIDs, because all flush_workqueue() does is wait
until all faults currently in the worqueue are processed. So it only
blocks the current thread, but nothing is lost.
>
> > + else
> > + ret = -ENODEV;
> > + mutex_unlock(¶m->lock);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(iopf_queue_flush_dev);
> > +
> > +/**
> > + * iopf_queue_discard_partial - Remove all pending partial fault
> > + * @queue: the queue whose partial faults need to be discarded
> > + *
> > + * When the hardware queue overflows, last page faults in a group may have been
> > + * lost and the IOMMU driver calls this to discard all partial faults. The
> > + * driver shouldn't be adding new faults to this queue concurrently.
> > + *
> > + * Return: 0 on success and <0 on error.
> > + */
> > +int iopf_queue_discard_partial(struct iopf_queue *queue)
> > +{
> > + struct iopf_fault *iopf, *next;
> > + struct iopf_device_param *iopf_param;
> > +
> > + if (!queue)
> > + return -EINVAL;
> > +
> > + mutex_lock(&queue->lock);
> > + list_for_each_entry(iopf_param, &queue->devices, queue_list) {
> > + list_for_each_entry_safe(iopf, next, &iopf_param->partial, head)
> > + kfree(iopf);
>
> iopf is freed but not removed from the list.
Ouch yes this is wrong, will fix.
>
> > + }
> > + mutex_unlock(&queue->lock);
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(iopf_queue_discard_partial);
> > +
> > +/**
> > + * iopf_queue_add_device - Add producer to the fault queue
> > + * @queue: IOPF queue
> > + * @dev: device to add
> > + *
> > + * Return: 0 on success and <0 on error.
> > + */
> > +int iopf_queue_add_device(struct iopf_queue *queue, struct device *dev)
> > +{
> > + int ret = -EBUSY;
> > + struct iopf_device_param *iopf_param;
> > + struct dev_iommu *param = dev->iommu;
> > +
> > + if (!param)
> > + return -ENODEV;
> > +
> > + iopf_param = kzalloc(sizeof(*iopf_param), GFP_KERNEL);
> > + if (!iopf_param)
> > + return -ENOMEM;
> > +
> > + INIT_LIST_HEAD(&iopf_param->partial);
> > + iopf_param->queue = queue;
> > + iopf_param->dev = dev;
> > +
> > + mutex_lock(&queue->lock);
> > + mutex_lock(¶m->lock);
> > + if (!param->iopf_param) {
> > + list_add(&iopf_param->queue_list, &queue->devices);
> > + param->iopf_param = iopf_param;
> > + ret = 0;
> > + }
> > + mutex_unlock(¶m->lock);
> > + mutex_unlock(&queue->lock);
> > +
> > + if (ret)
> > + kfree(iopf_param);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(iopf_queue_add_device);
> > +
> > +/**
> > + * iopf_queue_remove_device - Remove producer from fault queue
> > + * @queue: IOPF queue
> > + * @dev: device to remove
> > + *
> > + * Caller makes sure that no more faults are reported for this device.
> > + *
> > + * Return: 0 on success and <0 on error.
> > + */
> > +int iopf_queue_remove_device(struct iopf_queue *queue, struct device *dev)
> > +{
> > + int ret = 0;
> > + struct iopf_fault *iopf, *next;
> > + struct iopf_device_param *iopf_param;
> > + struct dev_iommu *param = dev->iommu;
> > +
> > + if (!param || !queue)
> > + return -EINVAL;
> > +
> > + mutex_lock(&queue->lock);
> > + mutex_lock(¶m->lock);
> > + iopf_param = param->iopf_param;
> > + if (iopf_param && iopf_param->queue == queue) {
> > + list_del(&iopf_param->queue_list);
> > + param->iopf_param = NULL;
> > + } else {
> > + ret = -EINVAL;
> > + }
> > + mutex_unlock(¶m->lock);
> > + mutex_unlock(&queue->lock);
> > + if (ret)
> > + return ret;
> > +
> > + /* Just in case some faults are still stuck */
> > + list_for_each_entry_safe(iopf, next, &iopf_param->partial, head)
> > + kfree(iopf);
>
> The same here.
Here is fine, we free the iopf_param below
Thanks,
Jean
>
> > +
> > + kfree(iopf_param);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(iopf_queue_remove_device);
WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: devicetree@vger.kernel.org, kevin.tian@intel.com,
jacob.jun.pan@linux.intel.com, jgg@ziepe.ca,
linux-pci@vger.kernel.org, joro@8bytes.org,
Jonathan.Cameron@huawei.com, robin.murphy@arm.com,
fenghua.yu@intel.com, hch@infradead.org, linux-mm@kvack.org,
iommu@lists.linux-foundation.org, zhangfei.gao@linaro.org,
catalin.marinas@arm.com, felix.kuehling@amd.com,
xuzaibo@huawei.com, will@kernel.org, christian.koenig@amd.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 04/25] iommu: Add a page fault handler
Date: Mon, 4 May 2020 18:22:42 +0200 [thread overview]
Message-ID: <20200504162242.GF170104@myrica> (raw)
In-Reply-To: <9a8ec004-0a9c-d772-8e7a-f839002a40b5@linux.intel.com>
On Sun, May 03, 2020 at 01:49:01PM +0800, Lu Baolu wrote:
> > +static void iopf_handle_group(struct work_struct *work)
> > +{
> > + struct iopf_group *group;
> > + struct iopf_fault *iopf, *next;
> > + enum iommu_page_response_code status = IOMMU_PAGE_RESP_SUCCESS;
> > +
> > + group = container_of(work, struct iopf_group, work);
> > +
> > + list_for_each_entry_safe(iopf, next, &group->faults, head) {
> > + /*
> > + * For the moment, errors are sticky: don't handle subsequent
> > + * faults in the group if there is an error.
> > + */
> > + if (status == IOMMU_PAGE_RESP_SUCCESS)
> > + status = iopf_handle_single(iopf);
> > +
> > + if (!(iopf->fault.prm.flags &
> > + IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE))
> > + kfree(iopf);
>
> The iopf is freed,but not removed from the list. This will cause wild
> pointer in code.
We free the list with the group below, so this one is fine.
>
> > + }
> > +
> > + iopf_complete_group(group->dev, &group->last_fault, status);
> > + kfree(group);
> > +}
> > +
>
> [...]
>
> > +/**
> > + * iopf_queue_flush_dev - Ensure that all queued faults have been processed
> > + * @dev: the endpoint whose faults need to be flushed.
> > + * @pasid: the PASID affected by this flush
> > + *
> > + * The IOMMU driver calls this before releasing a PASID, to ensure that all
> > + * pending faults for this PASID have been handled, and won't hit the address
> > + * space of the next process that uses this PASID. The driver must make sure
> > + * that no new fault is added to the queue. In particular it must flush its
> > + * low-level queue before calling this function.
> > + *
> > + * Return: 0 on success and <0 on error.
> > + */
> > +int iopf_queue_flush_dev(struct device *dev, int pasid)
> > +{
> > + int ret = 0;
> > + struct iopf_device_param *iopf_param;
> > + struct dev_iommu *param = dev->iommu;
> > +
> > + if (!param)
> > + return -ENODEV;
> > +
> > + mutex_lock(¶m->lock);
> > + iopf_param = param->iopf_param;
> > + if (iopf_param)
> > + flush_workqueue(iopf_param->queue->wq);
>
> There may be other pasid iopf in the workqueue. Flush all tasks in
> the workqueue will hurt other pasids. I might lose any context.
Granted this isn't optimal because we don't take the PASID argument into
account (I think I'll remove it, don't know how to use it). But I don't
think it affects other PASIDs, because all flush_workqueue() does is wait
until all faults currently in the worqueue are processed. So it only
blocks the current thread, but nothing is lost.
>
> > + else
> > + ret = -ENODEV;
> > + mutex_unlock(¶m->lock);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(iopf_queue_flush_dev);
> > +
> > +/**
> > + * iopf_queue_discard_partial - Remove all pending partial fault
> > + * @queue: the queue whose partial faults need to be discarded
> > + *
> > + * When the hardware queue overflows, last page faults in a group may have been
> > + * lost and the IOMMU driver calls this to discard all partial faults. The
> > + * driver shouldn't be adding new faults to this queue concurrently.
> > + *
> > + * Return: 0 on success and <0 on error.
> > + */
> > +int iopf_queue_discard_partial(struct iopf_queue *queue)
> > +{
> > + struct iopf_fault *iopf, *next;
> > + struct iopf_device_param *iopf_param;
> > +
> > + if (!queue)
> > + return -EINVAL;
> > +
> > + mutex_lock(&queue->lock);
> > + list_for_each_entry(iopf_param, &queue->devices, queue_list) {
> > + list_for_each_entry_safe(iopf, next, &iopf_param->partial, head)
> > + kfree(iopf);
>
> iopf is freed but not removed from the list.
Ouch yes this is wrong, will fix.
>
> > + }
> > + mutex_unlock(&queue->lock);
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(iopf_queue_discard_partial);
> > +
> > +/**
> > + * iopf_queue_add_device - Add producer to the fault queue
> > + * @queue: IOPF queue
> > + * @dev: device to add
> > + *
> > + * Return: 0 on success and <0 on error.
> > + */
> > +int iopf_queue_add_device(struct iopf_queue *queue, struct device *dev)
> > +{
> > + int ret = -EBUSY;
> > + struct iopf_device_param *iopf_param;
> > + struct dev_iommu *param = dev->iommu;
> > +
> > + if (!param)
> > + return -ENODEV;
> > +
> > + iopf_param = kzalloc(sizeof(*iopf_param), GFP_KERNEL);
> > + if (!iopf_param)
> > + return -ENOMEM;
> > +
> > + INIT_LIST_HEAD(&iopf_param->partial);
> > + iopf_param->queue = queue;
> > + iopf_param->dev = dev;
> > +
> > + mutex_lock(&queue->lock);
> > + mutex_lock(¶m->lock);
> > + if (!param->iopf_param) {
> > + list_add(&iopf_param->queue_list, &queue->devices);
> > + param->iopf_param = iopf_param;
> > + ret = 0;
> > + }
> > + mutex_unlock(¶m->lock);
> > + mutex_unlock(&queue->lock);
> > +
> > + if (ret)
> > + kfree(iopf_param);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(iopf_queue_add_device);
> > +
> > +/**
> > + * iopf_queue_remove_device - Remove producer from fault queue
> > + * @queue: IOPF queue
> > + * @dev: device to remove
> > + *
> > + * Caller makes sure that no more faults are reported for this device.
> > + *
> > + * Return: 0 on success and <0 on error.
> > + */
> > +int iopf_queue_remove_device(struct iopf_queue *queue, struct device *dev)
> > +{
> > + int ret = 0;
> > + struct iopf_fault *iopf, *next;
> > + struct iopf_device_param *iopf_param;
> > + struct dev_iommu *param = dev->iommu;
> > +
> > + if (!param || !queue)
> > + return -EINVAL;
> > +
> > + mutex_lock(&queue->lock);
> > + mutex_lock(¶m->lock);
> > + iopf_param = param->iopf_param;
> > + if (iopf_param && iopf_param->queue == queue) {
> > + list_del(&iopf_param->queue_list);
> > + param->iopf_param = NULL;
> > + } else {
> > + ret = -EINVAL;
> > + }
> > + mutex_unlock(¶m->lock);
> > + mutex_unlock(&queue->lock);
> > + if (ret)
> > + return ret;
> > +
> > + /* Just in case some faults are still stuck */
> > + list_for_each_entry_safe(iopf, next, &iopf_param->partial, head)
> > + kfree(iopf);
>
> The same here.
Here is fine, we free the iopf_param below
Thanks,
Jean
>
> > +
> > + kfree(iopf_param);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(iopf_queue_remove_device);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-05-04 16:22 UTC|newest]
Thread overview: 165+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-30 14:33 [PATCH v6 00/25] iommu: Shared Virtual Addressing for SMMUv3 Jean-Philippe Brucker
2020-04-30 14:33 ` Jean-Philippe Brucker
2020-04-30 14:33 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 01/25] mm: Add a PASID field to mm_struct Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-05-04 1:52 ` Xu Zaibo
2020-05-04 1:52 ` Xu Zaibo
2020-05-04 1:52 ` Xu Zaibo
2020-05-04 16:29 ` Jean-Philippe Brucker
2020-05-04 16:29 ` Jean-Philippe Brucker
2020-05-04 16:29 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 02/25] iommu/ioasid: Add ioasid references Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 18:39 ` Jacob Pan
2020-04-30 18:39 ` Jacob Pan
2020-04-30 18:39 ` Jacob Pan
2020-04-30 20:48 ` Jacob Pan
2020-04-30 20:48 ` Jacob Pan
2020-04-30 20:48 ` Jacob Pan
2020-05-04 14:39 ` Jean-Philippe Brucker
2020-05-04 14:39 ` Jean-Philippe Brucker
2020-05-04 14:39 ` Jean-Philippe Brucker
2020-05-04 15:22 ` Jacob Pan
2020-05-04 15:22 ` Jacob Pan
2020-05-04 15:22 ` Jacob Pan
2020-05-04 14:25 ` Jean-Philippe Brucker
2020-05-04 14:25 ` Jean-Philippe Brucker
2020-05-04 14:25 ` Jean-Philippe Brucker
2020-05-04 15:27 ` Jacob Pan
2020-05-04 15:27 ` Jacob Pan
2020-05-04 15:27 ` Jacob Pan
2020-04-30 14:34 ` [PATCH v6 03/25] iommu/sva: Add PASID helpers Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 04/25] iommu: Add a page fault handler Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-05-03 5:49 ` Lu Baolu
2020-05-03 5:49 ` Lu Baolu
2020-05-03 5:49 ` Lu Baolu
2020-05-04 16:22 ` Jean-Philippe Brucker [this message]
2020-05-04 16:22 ` Jean-Philippe Brucker
2020-05-04 16:22 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 05/25] iommu/iopf: Handle mm faults Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-05-03 5:54 ` Lu Baolu
2020-05-03 5:54 ` Lu Baolu
2020-05-03 5:54 ` Lu Baolu
2020-05-04 16:25 ` Jean-Philippe Brucker
2020-05-04 16:25 ` Jean-Philippe Brucker
2020-05-04 16:25 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 06/25] arm64: mm: Add asid_gen_match() helper Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 07/25] arm64: mm: Pin down ASIDs for sharing mm with devices Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 08/25] iommu/io-pgtable-arm: Move some definitions to a header Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 09/25] iommu/arm-smmu-v3: Manage ASIDs with xarray Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 10/25] arm64: cpufeature: Export symbol read_sanitised_ftr_reg() Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 15:18 ` Suzuki K Poulose
2020-04-30 15:18 ` Suzuki K Poulose
2020-04-30 15:18 ` Suzuki K Poulose
2020-04-30 14:34 ` [PATCH v6 11/25] iommu/arm-smmu-v3: Share process page tables Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 15:39 ` Suzuki K Poulose
2020-04-30 15:39 ` Suzuki K Poulose
2020-04-30 15:39 ` Suzuki K Poulose
2020-05-04 14:11 ` Jean-Philippe Brucker
2020-05-04 14:11 ` Jean-Philippe Brucker
2020-05-04 14:11 ` Jean-Philippe Brucker
2020-05-04 14:42 ` Suzuki K Poulose
2020-05-04 14:42 ` Suzuki K Poulose
2020-05-04 14:42 ` Suzuki K Poulose
2020-04-30 14:34 ` [PATCH v6 12/25] iommu/arm-smmu-v3: Seize private ASID Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 13/25] iommu/arm-smmu-v3: Add support for VHE Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 14/25] iommu/arm-smmu-v3: Enable broadcast TLB maintenance Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 15/25] iommu/arm-smmu-v3: Add SVA feature checking Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 16/25] iommu/arm-smmu-v3: Add SVA device feature Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 17/25] iommu/arm-smmu-v3: Implement iommu_sva_bind/unbind() Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 21:16 ` Jacob Pan
2020-04-30 21:16 ` Jacob Pan
2020-04-30 21:16 ` Jacob Pan
2020-05-04 16:43 ` Jean-Philippe Brucker
2020-05-04 16:43 ` Jean-Philippe Brucker
2020-05-04 16:43 ` Jean-Philippe Brucker
2020-05-04 20:47 ` Jacob Pan
2020-05-04 20:47 ` Jacob Pan
2020-05-04 20:47 ` Jacob Pan
2020-05-05 9:15 ` Jean-Philippe Brucker
2020-05-05 9:15 ` Jean-Philippe Brucker
2020-05-05 9:15 ` Jean-Philippe Brucker
2020-05-07 16:31 ` Jacob Pan
2020-05-07 16:31 ` Jacob Pan
2020-05-07 16:31 ` Jacob Pan
2020-05-01 12:15 ` Christoph Hellwig
2020-05-01 12:15 ` Christoph Hellwig
2020-05-01 12:15 ` Christoph Hellwig
2020-05-01 12:55 ` Jason Gunthorpe
2020-05-01 12:55 ` Jason Gunthorpe
2020-05-01 12:55 ` Jason Gunthorpe
2020-05-04 16:07 ` Jean-Philippe Brucker
2020-05-04 16:07 ` Jean-Philippe Brucker
2020-05-04 16:07 ` Jean-Philippe Brucker
2020-05-04 16:06 ` Jean-Philippe Brucker
2020-05-04 16:06 ` Jean-Philippe Brucker
2020-05-04 16:06 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 18/25] iommu/arm-smmu-v3: Hook up ATC invalidation to mm ops Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 19/25] iommu/arm-smmu-v3: Add support for Hardware Translation Table Update Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-05-04 14:24 ` Prabhakar Kushwaha
2020-05-04 14:24 ` Prabhakar Kushwaha
2020-05-04 14:24 ` Prabhakar Kushwaha
2020-05-04 16:35 ` Jean-Philippe Brucker
2020-05-04 16:35 ` Jean-Philippe Brucker
2020-05-04 16:35 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 20/25] iommu/arm-smmu-v3: Maintain a SID->device structure Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 21/25] dt-bindings: document stall property for IOMMU masters Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 22/25] iommu/arm-smmu-v3: Add stall support for platform devices Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 23/25] PCI/ATS: Add PRI stubs Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 24/25] PCI/ATS: Export PRI functions Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` [PATCH v6 25/25] iommu/arm-smmu-v3: Add support for PRI Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 14:34 ` Jean-Philippe Brucker
2020-04-30 21:18 ` [PATCH v6 00/25] iommu: Shared Virtual Addressing for SMMUv3 Jacob Pan
2020-04-30 21:18 ` Jacob Pan
2020-04-30 21:18 ` Jacob Pan
2020-05-04 15:09 ` Jean-Philippe Brucker
2020-05-04 15:09 ` Jean-Philippe Brucker
2020-05-04 15:09 ` 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=20200504162242.GF170104@myrica \
--to=jean-philippe@linaro.org \
--cc=baolu.lu@linux.intel.com \
--cc=catalin.marinas@arm.com \
--cc=christian.koenig@amd.com \
--cc=devicetree@vger.kernel.org \
--cc=felix.kuehling@amd.com \
--cc=fenghua.yu@intel.com \
--cc=hch@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jgg@ziepe.ca \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=linux-pci@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
--cc=zhangfei.gao@linaro.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: 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.