[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Tue, 2013-02-05 at 18:02 +0000, Keir Fraser wrote:
> On 05/02/2013 16:11, "Ian Campbell" <Ian.Campbell@xxxxxxxxxx> wrote:
> 
> >>> 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.
> > 
> > VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a page
> > by itself, even if that happens to be the Linux implementation today (I
> > haven't checked that).
> 
> Having guest agree that vcpu_info grows by size of the per-vcpu control
> block, if using this new event-channel interface, is reasonable though.

Can only use this trick once though, so it might be blocking ourselves
into a future ABI corner.

Is there a downside to registering the control block separately? The
guest can always arrange for them to be contiguous if it wants, or if we
are worried about the number of global mappings then the hypervisor
could require it shares a page with the vcpu_info but allow the offset
to be specified separately.

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.