From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: Scalable Event Channel ABI design (draft A) Date: Wed, 6 Feb 2013 10:42:07 +0000 Message-ID: <1360147327.7477.186.camel@zion.uk.xensource.com> References: <1360143520.23001.55.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1360143520.23001.55.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "Keir (Xen.org)" , wei.liu2@citrix.com, David Vrabel , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Wed, 2013-02-06 at 09:38 +0000, Ian Campbell wrote: > On Tue, 2013-02-05 at 18:02 +0000, Keir Fraser wrote: > > On 05/02/2013 16:11, "Ian Campbell" 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. > In practice embedding control block in vcpu_info might not be feasible because there is a legacy array of vcpu_info in shared_info page. It is quite easy to bloat shared_info to exceed size limit. > 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. > IMHO the global mapping space is the main concern. Regarding sharing page with vcpu_info, this requires us to control the way kernel handles its per-cpu section. But how? Wei. > Ian. >