From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zhigang Wang Subject: Re: increase evtchn limits Date: Fri, 21 May 2010 13:07:42 +0800 Message-ID: <4BF6151E.7050204@oracle.com> References: <20100520204110.2d421bfe@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100520204110.2d421bfe@mantra.us.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mukesh Rathor Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 05/21/2010 11:41 AM, Mukesh Rathor wrote: > Hi, > > I'm trying to boot up with lot more than 32 vcpus on this very large box. > I overcame vcpu_info[MAX_VIRT_CPUS] by doing vcpu placement hypercall > in guest, but now running into evt channel limit (lots of devices): > > unsigned long evtchn_pending[sizeof(unsigned long) * 8]; > I'm not sure, but it seems: 1024 for 32bit and 4096 for 64bit. 32bit: 4 * (4 * 8) * 8 = 1024 64bit: 8 * (8 * 8) * 8 = 4096 zhigang > which limits to 512 max for my 64bit dom0. The only recourse seems to > create a new struct shared_info_v2{}, and re-arrange it a bit with lot > more event channels. Since, start_info has magic with version info, I > can just check that in guest and use new shared_info...(doing the design > on the fly here). I can create a new vcpuop saying the guest is using > newer version. Or forget new version of shared_info{}, I can just > put evtchn stuff in my own mfn and tell hypervisor to relocate it, > (just like vcpu_info does) via new VCPUOP_ call. > > Keir, what do you think? > > thanks, > Mukesh > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel