Re: [Xen-devel] Scalable Event Channel ABI design (draft A)

[Keir Fraser <keir@xxxxxxx>]

On 05/02/2013 15:54, "David Vrabel" <david.vrabel@xxxxxxxxxx> wrote:

> On 05/02/13 15:49, Keir Fraser wrote:
>> On 05/02/2013 14:48, "David Vrabel" <david.vrabel@xxxxxxxxxx> 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?
> 
> I meant struct vcpu_info can be extended without it growing to more than
> a page.  i.e., it fits into the guest page provided in the
> VCPUOP_register_vcpu_info call so no additional pages need to be
> globally mapped for the control block.

Oh, I see so any guest that uses the new event-channel interface will
understand that vcpu_info is extended to contain it. Well, that makes sense.
It's not what your document says though.

 -- Keir

> David



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel