Re: [RFC] Extending numbers of event channels

[Tim Deegan <tim@xen.org>]

At 11:35 +0000 on 04 Dec (1354620912), David Vrabel wrote:
> On 03/12/12 20:56, Wei Liu wrote:
> > On Mon, Dec 03, 2012 at 06:52:41PM +0000, David Vrabel wrote:
> >> On 03/12/12 16:29, Wei Liu wrote:
> >>> Hi all
> >>>
> >>> There has been discussion on extending number of event channels back in
> >>> September [0].
> >>
> >> It seems that the decision has been made to go for this N-level
> >> approach.  Were any other methods considered?
> >>
> >> Would a per-VCPU ring of pending events work?  The ABI will be easier to
> >> extend in the future for more event channels.  The guest side code will
> >> be simpler.  It will be easier to fairly service the events as they will
> >> be processed in the order they were raised.
> >>
> >> The complexity would be in ensuring that events were not lost due to
> >> lack of space in the ring.  This may make the ring prohibitively large
> >> or require complex or expensive tracking of pending events inside Xen.
> >>
> > 
> > If I understand correctly, one event will always be queued up for
> > processing in the ring model, will this be too overkill? What if event
> > generation is much faster than processing?
> > 
> > In the current implementation, one event channel can be raised multiple
> > times but it is only processed once.
> 
> There would have to be something in Xen to ensure an event was only
> added to the ring once.  i.e., if it's already in the ring, it doesn't
> get added.  This is the tricky bit and I can't immediately think of how
> this would work.

Well, Xen could keep a bitmap of which events it had inserted in the
ring, and then the guest could clear bits from the bitmap as it serviced
the events... :)

More seriously, though, I prefer the existing bitmap interface.  It
handles masking and merging naturally, and it lets the guest service
events in whatever order it chooses (not having to process 1 word per
event of potentially uninteresting events off the ring to get to the one
it wants).

Tim.