From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Scalable Event Channel ABI design (draft A) Date: Tue, 05 Feb 2013 18:02:01 +0000 Message-ID: References: <1360080697.23001.28.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: <1360080697.23001.28.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 , David Vrabel Cc: Wei Liu , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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. -- Keir