On Mon, Jan 20, 2025 at 02:18:54PM -0400, Jason Gunthorpe wrote: > On Fri, Jan 17, 2025 at 02:11:15PM -0800, Nicolin Chen wrote: > > +/** > > + * struct iommufd_vevent_header - Virtual Event Header for a vEVENTQ Status > > + * @state: One of enum iommu_veventq_state > > I'd probably just make this a flag with overflow as the only current flag? Ack. > > + * @counter: A counter reflecting the state of the vEVENTQ > > > + * ---------------------------------------------------------------------------- > > + * | @state | @counter | > > + * ---------------------------------------------------------------------------- > > + * | IOMMU_VEVENTQ_STATE_OK | number of readable vEVENTs in the vEVENTQ | > > + * | IOMMU_VEVENTQ_STATE_OVERFLOW | number of missed vEVENTs since overflow | > > + * ---------------------------------------------------------------------------- > > When I said counter I literally ment a counter of the number of events > that were sent into the queue. So if events are dropped there is a > trivial gap in the count. Very easy to implement The counter of the number of events in the vEVENTQ could decrease when userspace reads the queue. But you were saying "the number of events that were sent into the queue", which is like a PROD index that would keep growing but reset to 0 after UINT_MAX? > IOMMU_VEVENTQ_STATE_OVERFLOW with a 0 length event is seen if events > have been lost and no subsequent events are present. It exists to > ensure timely delivery of the overflow event to userspace. counter > will be the sequence number of the next successful event. So userspace should first read the header to decide whether or not to read a vEVENT. If header is overflows, it should skip the vEVENT struct and read the next header? > If events are lost in the middle of the queue then flags will remain 0 > but counter will become non-montonic. A counter delta > 1 indicates > that many events have been lost. I don't quite get the "no subsequent events" v.s. "in the middle of the queue".. The producer is the driver calling iommufd_viommu_report_event that only produces a single vEVENT at a time. When the number of vEVENTs in the vEVENTQ hits the @veventq_depth, it won't insert new vEVENTs but add an overflow (or exception) node to the head of deliver list and increase the producer index so the next vEVENT that can find an empty space in the queue will have an index with a gap (delta >= 1)? Thanks Nicolin
