Re: [PATCH v2 03/11] iommu/arm-smmu-v3: Add arm_smmu_drain_queue_for_iopf() helper

[Pranjal Shrivastava <praan@google.com>]

On Tue, Jul 28, 2026 at 10:26:19PM -0700, Nicolin Chen wrote:
> On Wed, Jul 29, 2026 at 05:15:43AM +0000, Pranjal Shrivastava wrote:
> > For PRIQ/EVTQ, my only worry was the HW producing more events,
> > say Device A is detached (we call drain from attach_release) but Device B
> > (still attached) starts an agressive DMA with multiple PRI requests/evts.
> > 
> > Maybe we should go back to snapshot based polling for that?
> 
> If you look closely, "pending" is the snapshot, regardless of the
> growing prod.
> 
>  * With @until_empty == false (for EVTQ/PRIQ), exit once "drained" reaches its
>  * target: "pending" (i.e. prod0 - cons0, frozen at the entry time):
>  *
>  *   cons0                cons                 prod0         (prod)
>  *     |<---- drained ---->|                     |             |
>  *  ---+###################+=====================+=============+--->
>  *     |<--------------- pending --------------->|
> 

Right, but we write back cons to cons_reg only after we see queue_empty()
We have a do { .. } while (!queue_empty(llq)); and then we call
queue_sync_cons_ovf(q). Same  for PRIQ handler.

IIUC the helper relies on cons_reg being updated:

cons = readl_relaxed(q->cons_reg);
drained += Q_POS(&q->llq, cons - prev);

Thus, if we get a storm of pri reqs / evts, we may never leave that loop
and queue_sync_cons_ovf(q).

Let me know if I m missing anything?

Praan