Re: Scalable Event Channel ABI design (draft A)

[Keir Fraser <keir@xen.org>]

On 05/02/2013 14:48, "David Vrabel" <david.vrabel@citrix.com> wrote:

>> I have some sympathy for this design. It's primary downside compared with
>> the 3-level alternative is its greater space cost (32*#vcpus). However, as
>> you say the fairness and prioritisation features are rather nice. Also
>> having the data structures be per vcpu may well help avoid cacheline
>> contention on busy multi-vcpu guests.
> 
> This design originally (before I posted it) did have per-VCPU event
> arrays but I changed it to per-domain to reduce the memory footprint.

Okay, I wonder how much it actually matters anyhow...

Oh by the way you say the control block is 128 bytes and will easily fit in
the existing struct vcpu_info. That existing structure is 64 bytes in total.
So how does that work then?

 -- Keir

> A hybrid approach might be useful.  Busy guests like dom0 or driver
> domains could use per-VCPU event arrays but other guests could be
> per-domain.  This would be controlled by the toolstack.
>
>> Interested in what others think, but I may actually prefer a ground-up
>> redesign like this.
> 
> Since the ABI needs to be changed to support more event channels anyway,
> it seems an ideal point to revisit the design.