From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: [RFC] Extending numbers of event channels Date: Mon, 3 Dec 2012 18:09:28 +0000 Message-ID: <1354558168.18784.26.camel@iceland> References: <1354552154.18784.9.camel@iceland> <50BCF0F502000078000AD53F@nat28.tlf.novell.com> <1354557148.18784.21.camel@iceland> <50BCF6D502000078000AD6AB@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50BCF6D502000078000AD6AB@nat28.tlf.novell.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: Jan Beulich Cc: wei.liu2@citrix.com, Ian Campbell , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Mon, 2012-12-03 at 18:00 +0000, Jan Beulich wrote: > >>> On 03.12.12 at 18:52, Wei Liu wrote: > > On Mon, 2012-12-03 at 17:35 +0000, Jan Beulich wrote: > >> >>> On 03.12.12 at 17:29, Wei Liu wrote: > >> > Regarding Jan's comment in [0], I don't think allowing user to specify > >> > arbitrary number of levels a good idea. Because only the last level > >> > should be shared among vcpus, other level should be in percpu struct to > >> > allow for quicker lookup. The idea to let user specify levels will be > >> > too complicated in implementation and blow up percpu section (since the > >> > size grows exponentially). Three levels should be quite enough. See > >> > maths below. > >> > >> I didn't ask to implement more than three levels, I just asked for > >> the interface to establish the number of levels a guest wants to > >> use to allow for higher numbers (passing of which would result in > >> -EINVAL in your implementation). > >> > > > > Ah, I understand now. How about something like this: > > > > struct EVTCHNOP_reg_nlevel { > > int levels; > > void *level_specified_reg_struct; > > } > > Yes, just "unsigned int" please. > Right, "unsigned int". > >> > To sum up: > >> > 1. Guest should allocate pages for third level evtchn. > >> > 2. Guest should register third level pages via a new hypercall op. > >> > >> Doesn't the guest also need to set up space for the 2nd level? > >> > > > > Yes. That will be embedded in percpu struct vcpu_info, which will be > > also register via the same hypercall op. > > "struct vcpu_info"? Same hypercall? Or are you mixing up types? > What I meant was the second level will be embedded in struct vcpu_info, and the 2nd level will be registered via some hypercall (not the struct vcpu_info). Wei. > Jan >