Re: [PATCH v2 07/40] iommu: Add a page fault handler

[Jacob Pan]

On Thu, 24 May 2018 12:44:38 +0100
Jean-Philippe Brucker  wrote:

> On 23/05/18 00:35, Jacob Pan wrote:
>  +/* Insert *before* the last fault */
>  +list_move(>head, >faults);
>  +}
>  +
> >>> If you already sorted the group list with last fault at the end,
> >>> why do you need a separate entry to track the last fault?
> >>
> >> Not sure I understand your question, sorry. Do you mean why the
> >> iopf_group.last_fault? Just to avoid one more kzalloc.
> >>  
> > kind of :) what i thought was that why can't the last_fault
> > naturally be the last entry in your group fault list? then there is
> > no need for special treatment in terms of allocation of the last
> > fault. just my preference.  
> 
> But we need a kzalloc for the last fault anyway, so I thought I'd just
> piggy-back on the group allocation. And if I don't add the last fault
> at the end of group->faults, then it's iopf_handle_group that requires
> special treatment. I'm still not sure I understood your question
> though, could you send me a patch that does it?
> 
>  +
>  +queue->flush(queue->flush_arg, dev);
>  +
>  +/*
>  + * No need to clear the partial list. All PRGs
>  containing the PASID that
>  + * needs to be decommissioned are whole (the device
>  driver made sure of
>  + * it before this function was called). They have been
>  submitted to the
>  + * queue by the above flush().
>  + */
> >>> So you are saying device driver need to make sure LPIG PRQ is
> >>> submitted in the flush call above such that partial list is
> >>> cleared?
> >>
> >> Not exactly, it's the IOMMU driver that makes sure all LPIG in its
> >> queues are submitted by the above flush call. In more details the
> >> flow is:
> >>
> >> * Either device driver calls unbind()/sva_device_shutdown(), or the
> >> process exits.
> >> * If the device driver called, then it already told the device to
> >> stop using the PASID. Otherwise we use the mm_exit() callback to
> >> tell the device driver to stop using the PASID.
Sorry I still need more clarification. For the PASID termination
initiated by vfio unbind, I don't see device driver given a chance to
stop PASID. Seems just call __iommu_sva_unbind_device() which already
assume device stopped issuing DMA with the PASID.
So it is the vfio unbind caller responsible for doing driver callback
to stop DMA on a given PASID?

> >> * In either case, when receiving a stop request from the driver,
> >> the device sends the LPIGs to the IOMMU queue.
> >> * Then, the flush call above ensures that the IOMMU reports the
> >> LPIG with iommu_report_device_fault.
> >> * While submitting all LPIGs for this PASID to the work queue,
> >> ipof_queue_fault also picked up all partial faults, so the partial
> >> list is clean.
> >>
> >> Maybe I should improve this comment?
> >>  
> > thanks for explaining. LPIG submission is done by device
> > asynchronously w.r.t. driver stopping/decommission PASID.  
> 
> Hmm, it should really be synchronous, otherwise there is no way to
> know when the PASID can be decommissioned. We need a guarantee such
> as the one in 6.20.1 of the PCIe spec, "Managing PASID TLP Prefix
> Usage":
> 
> "When the stop request mechanism indicates completion, the Function
> has:
> * Completed all Non-Posted Requests associated with this PASID.
> * Flushed to the host all Posted Requests addressing host memory in
> all TCs that were used by the PASID."
> 
> That's in combination with "The function shall [...] finish
> transmitting any multi-page Page Request Messages for this PASID
> (i.e. send the Page Request Message with the L bit Set)." from the
> ATS spec.
> 
I am not contesting on the device side, what I meant was from the
host IOMMU driver perspective, LPIG is received via IOMMU host queue,
therefore asynchronous. Not sure about ARM, but on VT-d LPIG submission
could meet queue full condition. So per VT-d spec, iommu will generate a
successful auto response to the device. At this point, assume we
already stopped the given PASID on the device, there might not be
another LPIG sent for the device. Therefore, you could have a partial
list. I think we can just drop the requests in the partial list for
that PASID until the PASID gets re-allocated.


> (If I remember correctly a PRI Page Request is a Posted Request.) Only
> after this stop request completes can the driver call unbind(), or
> return from exit_mm(). Then we know that if there was a LPIG for that
> PASID, it is in the IOMMU's PRI queue (or already completed) once we
> call flush().
> 
agreed.
> > so if we were to use this
> > flow on vt-d, which does not stall page request queue, then we
> > should use the iommu model specific flush() callback to ensure LPIG
> > is received? There could be queue full condition and retry. I am
> > just trying to 

Re: [PATCH v2 07/40] iommu: Add a page fault handler

[Jean-Philippe Brucker]

On 23/05/18 00:35, Jacob Pan wrote:
 +  /* Insert *before* the last fault */
 +  list_move(>head, >faults);
 +  }
 +  
>>> If you already sorted the group list with last fault at the end,
>>> why do you need a separate entry to track the last fault?  
>>
>> Not sure I understand your question, sorry. Do you mean why the
>> iopf_group.last_fault? Just to avoid one more kzalloc.
>>
> kind of :) what i thought was that why can't the last_fault naturally
> be the last entry in your group fault list? then there is no need for
> special treatment in terms of allocation of the last fault. just my
> preference.

But we need a kzalloc for the last fault anyway, so I thought I'd just
piggy-back on the group allocation. And if I don't add the last fault at
the end of group->faults, then it's iopf_handle_group that requires
special treatment. I'm still not sure I understood your question though,
could you send me a patch that does it?

 +
 +  queue->flush(queue->flush_arg, dev);
 +
 +  /*
 +   * No need to clear the partial list. All PRGs containing
 the PASID that
 +   * needs to be decommissioned are whole (the device driver
 made sure of
 +   * it before this function was called). They have been
 submitted to the
 +   * queue by the above flush().
 +   */  
>>> So you are saying device driver need to make sure LPIG PRQ is
>>> submitted in the flush call above such that partial list is
>>> cleared?  
>>
>> Not exactly, it's the IOMMU driver that makes sure all LPIG in its
>> queues are submitted by the above flush call. In more details the
>> flow is:
>>
>> * Either device driver calls unbind()/sva_device_shutdown(), or the
>> process exits.
>> * If the device driver called, then it already told the device to stop
>> using the PASID. Otherwise we use the mm_exit() callback to tell the
>> device driver to stop using the PASID.
>> * In either case, when receiving a stop request from the driver, the
>> device sends the LPIGs to the IOMMU queue.
>> * Then, the flush call above ensures that the IOMMU reports the LPIG
>> with iommu_report_device_fault.
>> * While submitting all LPIGs for this PASID to the work queue,
>> ipof_queue_fault also picked up all partial faults, so the partial
>> list is clean.
>>
>> Maybe I should improve this comment?
>>
> thanks for explaining. LPIG submission is done by device asynchronously
> w.r.t. driver stopping/decommission PASID.

Hmm, it should really be synchronous, otherwise there is no way to know
when the PASID can be decommissioned. We need a guarantee such as the
one in 6.20.1 of the PCIe spec, "Managing PASID TLP Prefix Usage":

"When the stop request mechanism indicates completion, the Function has:
* Completed all Non-Posted Requests associated with this PASID.
* Flushed to the host all Posted Requests addressing host memory in all
TCs that were used by the PASID."

That's in combination with "The function shall [...] finish transmitting
any multi-page Page Request Messages for this PASID (i.e. send the Page
Request Message with the L bit Set)." from the ATS spec.

(If I remember correctly a PRI Page Request is a Posted Request.) Only
after this stop request completes can the driver call unbind(), or
return from exit_mm(). Then we know that if there was a LPIG for that
PASID, it is in the IOMMU's PRI queue (or already completed) once we
call flush().

> so if we were to use this
> flow on vt-d, which does not stall page request queue, then we should
> use the iommu model specific flush() callback to ensure LPIG is
> received? There could be queue full condition and retry. I am just
> trying to understand how and where we can make sure LPIG is
> received and all groups are whole.

For SMMU in patch 30, the flush() callback waits until the PRI queue is
empty or, when the PRI thread is running in parallel, until the thread
has done a full circle (handled as many faults as the queue size). It's
really unpleasant to implement because the flush() callback takes a lock
to inspect the hardware state, but I don't think we have a choice.

Thanks,
Jean
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2 07/40] iommu: Add a page fault handler

[Jacob Pan]

On Mon, 21 May 2018 15:49:40 +0100
Jean-Philippe Brucker  wrote:

> On 18/05/18 19:04, Jacob Pan wrote:
> >> +struct iopf_context {
> >> +  struct device   *dev;
> >> +  struct iommu_fault_eventevt;
> >> +  struct list_headhead;
> >> +};
> >> +
> >> +struct iopf_group {
> >> +  struct iopf_context last_fault;
> >> +  struct list_headfaults;
> >> +  struct work_struct  work;
> >> +};
> >> +  
> > All the page requests in the group should belong to the same device,
> > perhaps struct device tracking should be in iopf_group instead of
> > iopf_context?  
> 
> Right, this is a leftover from when we kept a global list of partial
> faults. Since the list is now per-device, I can move the dev pointer
> (I think I should also rename iopf_context to iopf_fault, if that's
> all right)
> 
> >> +static int iopf_complete(struct device *dev, struct
> >> iommu_fault_event *evt,
> >> +   enum page_response_code status)
> >> +{
> >> +  struct page_response_msg resp = {
> >> +  .addr   = evt->addr,
> >> +  .pasid  = evt->pasid,
> >> +  .pasid_present  = evt->pasid_valid,
> >> +  .page_req_group_id  =
> >> evt->page_req_group_id,
> >> +  .private_data   = evt->iommu_private,
> >> +  .resp_code  = status,
> >> +  };
> >> +
> >> +  return iommu_page_response(dev, );
> >> +}
> >> +
> >> +static enum page_response_code
> >> +iopf_handle_single(struct iopf_context *fault)
> >> +{
> >> +  /* TODO */
> >> +  return -ENODEV;
> >> +}
> >> +
> >> +static void iopf_handle_group(struct work_struct *work)
> >> +{
> >> +  struct iopf_group *group;
> >> +  struct iopf_context *fault, *next;
> >> +  enum page_response_code status = IOMMU_PAGE_RESP_SUCCESS;
> >> +
> >> +  group = container_of(work, struct iopf_group, work);
> >> +
> >> +  list_for_each_entry_safe(fault, next, >faults,
> >> head) {
> >> +  struct iommu_fault_event *evt = >evt;
> >> +  /*
> >> +   * Errors are sticky: don't handle subsequent
> >> faults in the
> >> +   * group if there is an error.
> >> +   */  
> > There might be performance benefit for certain device to continue in
> > spite of error in that the ATS retry may have less fault. Perhaps a
> > policy decision for later enhancement.  
> 
> Yes I think we should leave it to future work. My current reasoning is
> that subsequent requests are more likely to fail as well and reporting
> the error is more urgent, but we need real workloads to confirm this.
> 
> >> +  if (status == IOMMU_PAGE_RESP_SUCCESS)
> >> +  status = iopf_handle_single(fault);
> >> +
> >> +  if (!evt->last_req)
> >> +  kfree(fault);
> >> +  }
> >> +
> >> +  iopf_complete(group->last_fault.dev,
> >> >last_fault.evt, status);
> >> +  kfree(group);
> >> +}
> >> +
> >> +/**
> >> + * iommu_queue_iopf - IO Page Fault handler
> >> + * @evt: fault event
> >> + * @cookie: struct device, passed to
> >> iommu_register_device_fault_handler.
> >> + *
> >> + * Add a fault to the device workqueue, to be handled by mm.
> >> + */
> >> +int iommu_queue_iopf(struct iommu_fault_event *evt, void *cookie)
> >> +{
> >> +  struct iopf_group *group;
> >> +  struct iopf_context *fault, *next;
> >> +  struct iopf_device_param *iopf_param;
> >> +
> >> +  struct device *dev = cookie;
> >> +  struct iommu_param *param = dev->iommu_param;
> >> +
> >> +  if (WARN_ON(!mutex_is_locked(>lock)))
> >> +  return -EINVAL;
> >> +
> >> +  if (evt->type != IOMMU_FAULT_PAGE_REQ)
> >> +  /* Not a recoverable page fault */
> >> +  return IOMMU_PAGE_RESP_CONTINUE;
> >> +
> >> +  /*
> >> +   * As long as we're holding param->lock, the queue can't
> >> be unlinked
> >> +   * from the device and therefore cannot disappear.
> >> +   */
> >> +  iopf_param = param->iopf_param;
> >> +  if (!iopf_param)
> >> +  return -ENODEV;
> >> +
> >> +  if (!evt->last_req) {
> >> +  fault = kzalloc(sizeof(*fault), GFP_KERNEL);
> >> +  if (!fault)
> >> +  return -ENOMEM;
> >> +
> >> +  fault->evt = *evt;
> >> +  fault->dev = dev;
> >> +
> >> +  /* Non-last request of a group. Postpone until the
> >> last one */
> >> +  list_add(>head, _param->partial);
> >> +
> >> +  return IOMMU_PAGE_RESP_HANDLED;
> >> +  }
> >> +
> >> +  group = kzalloc(sizeof(*group), GFP_KERNEL);
> >> +  if (!group)
> >> +  return -ENOMEM;
> >> +
> >> +  group->last_fault.evt = *evt;
> >> +  group->last_fault.dev = dev;
> >> +  INIT_LIST_HEAD(>faults);
> >> +  list_add(>last_fault.head, >faults);
> >> +  INIT_WORK(>work, iopf_handle_group);
> >> +
> >> +  /* See if we have partial faults for this group */
> >> +  list_for_each_entry_safe(fault, next,
> >> _param->partial, head) {
> >> +  if 

Re: [PATCH v2 07/40] iommu: Add a page fault handler

[Jean-Philippe Brucker]

On 18/05/18 19:04, Jacob Pan wrote:
>> +struct iopf_context {
>> +struct device   *dev;
>> +struct iommu_fault_eventevt;
>> +struct list_headhead;
>> +};
>> +
>> +struct iopf_group {
>> +struct iopf_context last_fault;
>> +struct list_headfaults;
>> +struct work_struct  work;
>> +};
>> +
> All the page requests in the group should belong to the same device,
> perhaps struct device tracking should be in iopf_group instead of
> iopf_context?

Right, this is a leftover from when we kept a global list of partial
faults. Since the list is now per-device, I can move the dev pointer (I
think I should also rename iopf_context to iopf_fault, if that's all right)

>> +static int iopf_complete(struct device *dev, struct
>> iommu_fault_event *evt,
>> + enum page_response_code status)
>> +{
>> +struct page_response_msg resp = {
>> +.addr   = evt->addr,
>> +.pasid  = evt->pasid,
>> +.pasid_present  = evt->pasid_valid,
>> +.page_req_group_id  = evt->page_req_group_id,
>> +.private_data   = evt->iommu_private,
>> +.resp_code  = status,
>> +};
>> +
>> +return iommu_page_response(dev, );
>> +}
>> +
>> +static enum page_response_code
>> +iopf_handle_single(struct iopf_context *fault)
>> +{
>> +/* TODO */
>> +return -ENODEV;
>> +}
>> +
>> +static void iopf_handle_group(struct work_struct *work)
>> +{
>> +struct iopf_group *group;
>> +struct iopf_context *fault, *next;
>> +enum page_response_code status = IOMMU_PAGE_RESP_SUCCESS;
>> +
>> +group = container_of(work, struct iopf_group, work);
>> +
>> +list_for_each_entry_safe(fault, next, >faults, head) {
>> +struct iommu_fault_event *evt = >evt;
>> +/*
>> + * Errors are sticky: don't handle subsequent faults
>> in the
>> + * group if there is an error.
>> + */
> There might be performance benefit for certain device to continue in
> spite of error in that the ATS retry may have less fault. Perhaps a
> policy decision for later enhancement.

Yes I think we should leave it to future work. My current reasoning is
that subsequent requests are more likely to fail as well and reporting
the error is more urgent, but we need real workloads to confirm this.

>> +if (status == IOMMU_PAGE_RESP_SUCCESS)
>> +status = iopf_handle_single(fault);
>> +
>> +if (!evt->last_req)
>> +kfree(fault);
>> +}
>> +
>> +iopf_complete(group->last_fault.dev, >last_fault.evt,
>> status);
>> +kfree(group);
>> +}
>> +
>> +/**
>> + * iommu_queue_iopf - IO Page Fault handler
>> + * @evt: fault event
>> + * @cookie: struct device, passed to
>> iommu_register_device_fault_handler.
>> + *
>> + * Add a fault to the device workqueue, to be handled by mm.
>> + */
>> +int iommu_queue_iopf(struct iommu_fault_event *evt, void *cookie)
>> +{
>> +struct iopf_group *group;
>> +struct iopf_context *fault, *next;
>> +struct iopf_device_param *iopf_param;
>> +
>> +struct device *dev = cookie;
>> +struct iommu_param *param = dev->iommu_param;
>> +
>> +if (WARN_ON(!mutex_is_locked(>lock)))
>> +return -EINVAL;
>> +
>> +if (evt->type != IOMMU_FAULT_PAGE_REQ)
>> +/* Not a recoverable page fault */
>> +return IOMMU_PAGE_RESP_CONTINUE;
>> +
>> +/*
>> + * As long as we're holding param->lock, the queue can't be
>> unlinked
>> + * from the device and therefore cannot disappear.
>> + */
>> +iopf_param = param->iopf_param;
>> +if (!iopf_param)
>> +return -ENODEV;
>> +
>> +if (!evt->last_req) {
>> +fault = kzalloc(sizeof(*fault), GFP_KERNEL);
>> +if (!fault)
>> +return -ENOMEM;
>> +
>> +fault->evt = *evt;
>> +fault->dev = dev;
>> +
>> +/* Non-last request of a group. Postpone until the
>> last one */
>> +list_add(>head, _param->partial);
>> +
>> +return IOMMU_PAGE_RESP_HANDLED;
>> +}
>> +
>> +group = kzalloc(sizeof(*group), GFP_KERNEL);
>> +if (!group)
>> +return -ENOMEM;
>> +
>> +group->last_fault.evt = *evt;
>> +group->last_fault.dev = dev;
>> +INIT_LIST_HEAD(>faults);
>> +list_add(>last_fault.head, >faults);
>> +INIT_WORK(>work, iopf_handle_group);
>> +
>> +/* See if we have partial faults for this group */
>> +list_for_each_entry_safe(fault, next, _param->partial,
>> head) {
>> +if (fault->evt.page_req_group_id ==
>> evt->page_req_group_id)
> If all 9 bit group index are used, there can be lots of PRGs. For
> future enhancement, maybe we can have per group partial list ready to
> go when LPIG comes in? I will be less searching.

Yes, 

Re: [PATCH v2 07/40] iommu: Add a page fault handler

[Jean-Philippe Brucker]

On 17/05/18 16:25, Jonathan Cameron wrote:
> On Fri, 11 May 2018 20:06:08 +0100
> Jean-Philippe Brucker  wrote:
> 
>> Some systems allow devices to handle I/O Page Faults in the core mm. For
>> example systems implementing the PCI PRI extension or Arm SMMU stall
>> model. Infrastructure for reporting these recoverable page faults was
>> recently added to the IOMMU core for SVA virtualisation. Add a page fault
>> handler for host SVA.
>>
>> IOMMU driver can now instantiate several fault workqueues and link them to
>> IOPF-capable devices. Drivers can choose between a single global
>> workqueue, one per IOMMU device, one per low-level fault queue, one per
>> domain, etc.
>>
>> When it receives a fault event, supposedly in an IRQ handler, the IOMMU
>> driver reports the fault using iommu_report_device_fault(), which calls
>> the registered handler. The page fault handler then calls the mm fault
>> handler, and reports either success or failure with iommu_page_response().
>> When the handler succeeded, the IOMMU retries the access.
>>
>> The iopf_param pointer could be embedded into iommu_fault_param. But
>> putting iopf_param into the iommu_param structure allows us not to care
>> about ordering between calls to iopf_queue_add_device() and
>> iommu_register_device_fault_handler().
>>
>> Signed-off-by: Jean-Philippe Brucker 
> 
> Hi Jean-Phillipe,
> 
> One question below on how we would end up with partial faults left when
> doing the queue remove. Code looks fine, but I'm not seeing how that
> would happen without buggy hardware... + we presumably have to rely on
> the hardware timing out on that request or it's dead anyway...

>> +/**
>> + * iopf_queue_remove_device - Remove producer from fault queue
>> + * @dev: device to remove
>> + *
>> + * Caller makes sure that no more fault is reported for this device, and no 
>> more
>> + * flush is scheduled for this device.
>> + *
>> + * Note: safe to call unconditionally on a cleanup path, even if the device
>> + * isn't registered to any IOPF queue.
>> + *
>> + * Return 0 if the device was attached to the IOPF queue
>> + */
>> +int iopf_queue_remove_device(struct device *dev)
>> +{
>> +struct iopf_context *fault, *next;
>> +struct iopf_device_param *iopf_param;
>> +struct iommu_param *param = dev->iommu_param;
>> +
>> +if (!param)
>> +return -EINVAL;
>> +
>> +mutex_lock(>lock);
>> +iopf_param = param->iopf_param;
>> +if (iopf_param) {
>> +refcount_dec(_param->queue->refs);
>> +param->iopf_param = NULL;
>> +}
>> +mutex_unlock(>lock);
>> +if (!iopf_param)
>> +return -EINVAL;
>> +
>> +list_for_each_entry_safe(fault, next, _param->partial, head)
>> +kfree(fault);
>> +
> 
> Why would we end up here with partials still in the list?  Buggy hardware?

Buggy hardware is one possibility. There also is the nasty case of PRI
queue overflow. If the PRI queue is full, then the SMMU discards new
Page Requests from the device. It may discard a 'last' PR of a group
that is already in iopf_param->partial. This group will never be freed
until this cleanup.

The spec dismisses PRIq overflows because the OS is supposed to allocate
PRI credits to devices such that they can't send more than the PRI queue
size. This isn't possible in Linux because we don't know exactly how
many PRI-capable devices will share a queue (the upper limit is 2**32,
and devices may be hotplugged well after we allocated the PRI queue). So
PRIq overflow is possible.

Ideally when detecting a PRIq overflow we need to immediately remove all
partial faults of all devices sharing this queue. Since I can't easily
test that case (my device doesn't do PRGs) and it's complicated code, I
left it as TODO in patch 39, and this is our only chance to free
orphaned page requests.

>> +void iopf_queue_free(struct iopf_queue *queue)
>> +{
>> +
> 
> Nitpick : Blank line here doesn't add anything.

Ok

Thanks,
Jean
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2 07/40] iommu: Add a page fault handler

[Jacob Pan]

On Fri, 11 May 2018 20:06:08 +0100
Jean-Philippe Brucker  wrote:

> Some systems allow devices to handle I/O Page Faults in the core mm.
> For example systems implementing the PCI PRI extension or Arm SMMU
> stall model. Infrastructure for reporting these recoverable page
> faults was recently added to the IOMMU core for SVA virtualisation.
> Add a page fault handler for host SVA.
> 
> IOMMU driver can now instantiate several fault workqueues and link
> them to IOPF-capable devices. Drivers can choose between a single
> global workqueue, one per IOMMU device, one per low-level fault
> queue, one per domain, etc.
> 
> When it receives a fault event, supposedly in an IRQ handler, the
> IOMMU driver reports the fault using iommu_report_device_fault(),
> which calls the registered handler. The page fault handler then calls
> the mm fault handler, and reports either success or failure with
> iommu_page_response(). When the handler succeeded, the IOMMU retries
> the access.
> 
> The iopf_param pointer could be embedded into iommu_fault_param. But
> putting iopf_param into the iommu_param structure allows us not to
> care about ordering between calls to iopf_queue_add_device() and
> iommu_register_device_fault_handler().
> 
> Signed-off-by: Jean-Philippe Brucker 
> 
> ---
> v1->v2: multiple queues registered by IOMMU driver
> ---
>  drivers/iommu/Kconfig  |   4 +
>  drivers/iommu/Makefile |   1 +
>  drivers/iommu/io-pgfault.c | 363
> + include/linux/iommu.h  |
> 58 ++ 4 files changed, 426 insertions(+)
>  create mode 100644 drivers/iommu/io-pgfault.c
> 
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 38434899e283..09f13a7c4b60 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -79,6 +79,10 @@ config IOMMU_SVA
>   select IOMMU_API
>   select MMU_NOTIFIER
>  
> +config IOMMU_PAGE_FAULT
> + bool
> + select IOMMU_API
> +
>  config FSL_PAMU
>   bool "Freescale IOMMU support"
>   depends on PCI
> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> index 1dbcc89ebe4c..4b744e399a1b 100644
> --- a/drivers/iommu/Makefile
> +++ b/drivers/iommu/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_IOMMU_API) += iommu-traces.o
>  obj-$(CONFIG_IOMMU_API) += iommu-sysfs.o
>  obj-$(CONFIG_IOMMU_DMA) += dma-iommu.o
>  obj-$(CONFIG_IOMMU_SVA) += iommu-sva.o
> +obj-$(CONFIG_IOMMU_PAGE_FAULT) += io-pgfault.o
>  obj-$(CONFIG_IOMMU_IO_PGTABLE) += io-pgtable.o
>  obj-$(CONFIG_IOMMU_IO_PGTABLE_ARMV7S) += io-pgtable-arm-v7s.o
>  obj-$(CONFIG_IOMMU_IO_PGTABLE_LPAE) += io-pgtable-arm.o
> diff --git a/drivers/iommu/io-pgfault.c b/drivers/iommu/io-pgfault.c
> new file mode 100644
> index ..321c00dd3a3d
> --- /dev/null
> +++ b/drivers/iommu/io-pgfault.c
> @@ -0,0 +1,363 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Handle device page faults
> + *
> + * Copyright (C) 2018 ARM Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * struct iopf_queue - IO Page Fault queue
> + * @wq: the fault workqueue
> + * @flush: low-level flush callback
> + * @flush_arg: flush() argument
> + * @refs: references to this structure taken by producers
> + */
> +struct iopf_queue {
> + struct workqueue_struct *wq;
> + iopf_queue_flush_t  flush;
> + void*flush_arg;
> + refcount_t  refs;
> +};
> +
> +/**
> + * struct iopf_device_param - IO Page Fault data attached to a device
> + * @queue: IOPF queue
> + * @partial: faults that are part of a Page Request Group for which
> the last
> + *   request hasn't been submitted yet.
> + */
> +struct iopf_device_param {
> + struct iopf_queue   *queue;
> + struct list_headpartial;
> +};
> +
> +struct iopf_context {
> + struct device   *dev;
> + struct iommu_fault_eventevt;
> + struct list_headhead;
> +};
> +
> +struct iopf_group {
> + struct iopf_context last_fault;
> + struct list_headfaults;
> + struct work_struct  work;
> +};
> +
All the page requests in the group should belong to the same device,
perhaps struct device tracking should be in iopf_group instead of
iopf_context?

> +static int iopf_complete(struct device *dev, struct
> iommu_fault_event *evt,
> +  enum page_response_code status)
> +{
> + struct page_response_msg resp = {
> + .addr   = evt->addr,
> + .pasid  = evt->pasid,
> + .pasid_present  = evt->pasid_valid,
> + .page_req_group_id  = evt->page_req_group_id,
> + .private_data   = evt->iommu_private,
> + .resp_code  = status,
> + };
> +
> + return iommu_page_response(dev, );
> +}
> +
> +static 

Re: [PATCH v2 07/40] iommu: Add a page fault handler

[Jonathan Cameron]

On Fri, 11 May 2018 20:06:08 +0100
Jean-Philippe Brucker  wrote:

> Some systems allow devices to handle I/O Page Faults in the core mm. For
> example systems implementing the PCI PRI extension or Arm SMMU stall
> model. Infrastructure for reporting these recoverable page faults was
> recently added to the IOMMU core for SVA virtualisation. Add a page fault
> handler for host SVA.
> 
> IOMMU driver can now instantiate several fault workqueues and link them to
> IOPF-capable devices. Drivers can choose between a single global
> workqueue, one per IOMMU device, one per low-level fault queue, one per
> domain, etc.
> 
> When it receives a fault event, supposedly in an IRQ handler, the IOMMU
> driver reports the fault using iommu_report_device_fault(), which calls
> the registered handler. The page fault handler then calls the mm fault
> handler, and reports either success or failure with iommu_page_response().
> When the handler succeeded, the IOMMU retries the access.
> 
> The iopf_param pointer could be embedded into iommu_fault_param. But
> putting iopf_param into the iommu_param structure allows us not to care
> about ordering between calls to iopf_queue_add_device() and
> iommu_register_device_fault_handler().
> 
> Signed-off-by: Jean-Philippe Brucker 

Hi Jean-Phillipe,

One question below on how we would end up with partial faults left when
doing the queue remove. Code looks fine, but I'm not seeing how that
would happen without buggy hardware... + we presumably have to rely on
the hardware timing out on that request or it's dead anyway...

Jonathan

> 
> ---
> v1->v2: multiple queues registered by IOMMU driver
> ---
>  drivers/iommu/Kconfig  |   4 +
>  drivers/iommu/Makefile |   1 +
>  drivers/iommu/io-pgfault.c | 363 +
>  include/linux/iommu.h  |  58 ++
>  4 files changed, 426 insertions(+)
>  create mode 100644 drivers/iommu/io-pgfault.c
> 
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 38434899e283..09f13a7c4b60 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -79,6 +79,10 @@ config IOMMU_SVA
>   select IOMMU_API
>   select MMU_NOTIFIER
>  
> +config IOMMU_PAGE_FAULT
> + bool
> + select IOMMU_API
> +
>  config FSL_PAMU
>   bool "Freescale IOMMU support"
>   depends on PCI
> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> index 1dbcc89ebe4c..4b744e399a1b 100644
> --- a/drivers/iommu/Makefile
> +++ b/drivers/iommu/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_IOMMU_API) += iommu-traces.o
>  obj-$(CONFIG_IOMMU_API) += iommu-sysfs.o
>  obj-$(CONFIG_IOMMU_DMA) += dma-iommu.o
>  obj-$(CONFIG_IOMMU_SVA) += iommu-sva.o
> +obj-$(CONFIG_IOMMU_PAGE_FAULT) += io-pgfault.o
>  obj-$(CONFIG_IOMMU_IO_PGTABLE) += io-pgtable.o
>  obj-$(CONFIG_IOMMU_IO_PGTABLE_ARMV7S) += io-pgtable-arm-v7s.o
>  obj-$(CONFIG_IOMMU_IO_PGTABLE_LPAE) += io-pgtable-arm.o
> diff --git a/drivers/iommu/io-pgfault.c b/drivers/iommu/io-pgfault.c
> new file mode 100644
> index ..321c00dd3a3d
> --- /dev/null
> +++ b/drivers/iommu/io-pgfault.c
> @@ -0,0 +1,363 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Handle device page faults
> + *
> + * Copyright (C) 2018 ARM Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * struct iopf_queue - IO Page Fault queue
> + * @wq: the fault workqueue
> + * @flush: low-level flush callback
> + * @flush_arg: flush() argument
> + * @refs: references to this structure taken by producers
> + */
> +struct iopf_queue {
> + struct workqueue_struct *wq;
> + iopf_queue_flush_t  flush;
> + void*flush_arg;
> + refcount_t  refs;
> +};
> +
> +/**
> + * struct iopf_device_param - IO Page Fault data attached to a device
> + * @queue: IOPF queue
> + * @partial: faults that are part of a Page Request Group for which the last
> + *   request hasn't been submitted yet.
> + */
> +struct iopf_device_param {
> + struct iopf_queue   *queue;
> + struct list_headpartial;
> +};
> +
> +struct iopf_context {
> + struct device   *dev;
> + struct iommu_fault_eventevt;
> + struct list_headhead;
> +};
> +
> +struct iopf_group {
> + struct iopf_context last_fault;
> + struct list_headfaults;
> + struct work_struct  work;
> +};
> +
> +static int iopf_complete(struct device *dev, struct iommu_fault_event *evt,
> +  enum page_response_code status)
> +{
> + struct page_response_msg resp = {
> + .addr   = evt->addr,
> + .pasid  = evt->pasid,
> + .pasid_present  = evt->pasid_valid,
> + .page_req_group_id  = evt->page_req_group_id,
> + .private_data 

[PATCH v2 07/40] iommu: Add a page fault handler

[Jean-Philippe Brucker]

Some systems allow devices to handle I/O Page Faults in the core mm. For
example systems implementing the PCI PRI extension or Arm SMMU stall
model. Infrastructure for reporting these recoverable page faults was
recently added to the IOMMU core for SVA virtualisation. Add a page fault
handler for host SVA.

IOMMU driver can now instantiate several fault workqueues and link them to
IOPF-capable devices. Drivers can choose between a single global
workqueue, one per IOMMU device, one per low-level fault queue, one per
domain, etc.

When it receives a fault event, supposedly in an IRQ handler, the IOMMU
driver reports the fault using iommu_report_device_fault(), which calls
the registered handler. The page fault handler then calls the mm fault
handler, and reports either success or failure with iommu_page_response().
When the handler succeeded, the IOMMU retries the access.

The iopf_param pointer could be embedded into iommu_fault_param. But
putting iopf_param into the iommu_param structure allows us not to care
about ordering between calls to iopf_queue_add_device() and
iommu_register_device_fault_handler().

Signed-off-by: Jean-Philippe Brucker 

---
v1->v2: multiple queues registered by IOMMU driver
---
 drivers/iommu/Kconfig  |   4 +
 drivers/iommu/Makefile |   1 +
 drivers/iommu/io-pgfault.c | 363 +
 include/linux/iommu.h  |  58 ++
 4 files changed, 426 insertions(+)
 create mode 100644 drivers/iommu/io-pgfault.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 38434899e283..09f13a7c4b60 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -79,6 +79,10 @@ config IOMMU_SVA
select IOMMU_API
select MMU_NOTIFIER
 
+config IOMMU_PAGE_FAULT
+   bool
+   select IOMMU_API
+
 config FSL_PAMU
bool "Freescale IOMMU support"
depends on PCI
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 1dbcc89ebe4c..4b744e399a1b 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_IOMMU_API) += iommu-traces.o
 obj-$(CONFIG_IOMMU_API) += iommu-sysfs.o
 obj-$(CONFIG_IOMMU_DMA) += dma-iommu.o
 obj-$(CONFIG_IOMMU_SVA) += iommu-sva.o
+obj-$(CONFIG_IOMMU_PAGE_FAULT) += io-pgfault.o
 obj-$(CONFIG_IOMMU_IO_PGTABLE) += io-pgtable.o
 obj-$(CONFIG_IOMMU_IO_PGTABLE_ARMV7S) += io-pgtable-arm-v7s.o
 obj-$(CONFIG_IOMMU_IO_PGTABLE_LPAE) += io-pgtable-arm.o
diff --git a/drivers/iommu/io-pgfault.c b/drivers/iommu/io-pgfault.c
new file mode 100644
index ..321c00dd3a3d
--- /dev/null
+++ b/drivers/iommu/io-pgfault.c
@@ -0,0 +1,363 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Handle device page faults
+ *
+ * Copyright (C) 2018 ARM Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct iopf_queue - IO Page Fault queue
+ * @wq: the fault workqueue
+ * @flush: low-level flush callback
+ * @flush_arg: flush() argument
+ * @refs: references to this structure taken by producers
+ */
+struct iopf_queue {
+   struct workqueue_struct *wq;
+   iopf_queue_flush_t  flush;
+   void*flush_arg;
+   refcount_t  refs;
+};
+
+/**
+ * struct iopf_device_param - IO Page Fault data attached to a device
+ * @queue: IOPF queue
+ * @partial: faults that are part of a Page Request Group for which the last
+ *   request hasn't been submitted yet.
+ */
+struct iopf_device_param {
+   struct iopf_queue   *queue;
+   struct list_headpartial;
+};
+
+struct iopf_context {
+   struct device   *dev;
+   struct iommu_fault_eventevt;
+   struct list_headhead;
+};
+
+struct iopf_group {
+   struct iopf_context last_fault;
+   struct list_headfaults;
+   struct work_struct  work;
+};
+
+static int iopf_complete(struct device *dev, struct iommu_fault_event *evt,
+enum page_response_code status)
+{
+   struct page_response_msg resp = {
+   .addr   = evt->addr,
+   .pasid  = evt->pasid,
+   .pasid_present  = evt->pasid_valid,
+   .page_req_group_id  = evt->page_req_group_id,
+   .private_data   = evt->iommu_private,
+   .resp_code  = status,
+   };
+
+   return iommu_page_response(dev, );
+}
+
+static enum page_response_code
+iopf_handle_single(struct iopf_context *fault)
+{
+   /* TODO */
+   return -ENODEV;
+}
+
+static void iopf_handle_group(struct work_struct *work)
+{
+   struct iopf_group *group;
+   struct iopf_context *fault, *next;
+   enum page_response_code status = IOMMU_PAGE_RESP_SUCCESS;
+
+   group = container_of(work, struct iopf_group, work);
+
+   list_for_each_entry_safe(fault, next, >faults, head) {
+