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

[Nicolin Chen <nicolinc@nvidia.com>]

On Wed, Jul 29, 2026 at 05:46:23AM +0000, Pranjal Shrivastava wrote:
> 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).

cons_reg is updated by queue_remove_raw() every iteration inside
that loop.

queue_sync_cons_ovf() doesn't update cons_reg unless an overflow.

Nicolin