From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: FIFO-based event channel ABI design (draft B) Date: Fri, 15 Feb 2013 19:04:27 +0000 Message-ID: <1360955067.16636.201.camel@zion.uk.xensource.com> References: <511E46FD.3010605@citrix.com> <1360952378.16636.195.camel@zion.uk.xensource.com> <511E829B.8020800@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <511E829B.8020800@citrix.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: David Vrabel Cc: "xen-devel@lists.xensource.com" , wei.liu2@citrix.com List-Id: xen-devel@lists.xenproject.org On Fri, 2013-02-15 at 18:46 +0000, David Vrabel wrote: > On 15/02/13 18:19, Wei Liu wrote: > > Apart from the TAIL field, I have some comments on the hypercall > > interface. Please see inline comments. > > > > On Fri, 2013-02-15 at 14:32 +0000, David Vrabel wrote: > >> > >> ### `EVTCHNOP_init_control` > >> > >> This call initializes a single VCPU's control block. > >> > >> A guest should call this during initial VCPU bring up. The guest must > >> have already successfully registered a vcpu_info structure and the > >> control block must be in the same page. > >> > >> If this call fails on the boot VCPU, the guest should continue to use > >> the 2-level event channel ABI for all VCPUs. If this call fails on > >> any non-boot VCPU then the VCPU will be unable to receive events and > >> the guest should offline the VCPU. > >> > > > > Why offline this CPU? This call only registers control block, we can > > switch back to use 2-level for all CPUs. > > Because switching back for the other VCPUs is potentially impossible (we > may have hotplugged this new VCPU and more than 4096 event channels may > be currently in use). It would also require migrating events between > the new and old data structures which is hard. > If you hot plug a vcpu, can it possibly bypass the cpu_possible_map limit? VCPU info placement call is issued for all possible CPU's, in this case, you can have new ABI setup for all possible CPUs at start-of-day, so there is no migration needed. > I would expect this call to never fail in normal operation (except on > the boot VCPU where support may be missing). i.e., it will only fail if > xenheap or map space is exhausted. Both the xenheap and the map space > should be large enough so we run out of other resources (e.g,, domheap) > first. > [snip] > > The boot VCPU shall have successfully initialized its control block. I > don't think there are any other restrictions on this call. > So do you mean that this is only called when guest starts? Wei.