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

On Wed, Jul 29, 2026 at 09:47:45AM -0700, Nicolin Chen wrote:
> 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.
> 

Ahh right, I was too focused on the storm *facepalm*. In that case the
new helper LGTM.

Thanks,
Praan