From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mukesh Rathor <mukesh.rathor@oracle.com>
Subject: Re: [PATCHEs]: support more than 32 VCPUs in guests
Date: Fri, 16 Jul 2010 18:06:13 -0700
Message-ID: <20100716180613.520ce8bc@mantra.us.oracle.com>
References: <20100609160920.1445fbbe@mantra.us.oracle.com>
	<4C102742.3010108@goop.org>
	<20100609170825.06a67ff9@mantra.us.oracle.com>
	<4C1036B0.4060905@goop.org>
	<20100609191332.588a15d1@mantra.us.oracle.com>
	<4C15F85A.1050804@goop.org>
	<20100614194926.2f81ed3d@mantra.us.oracle.com>
	<4C173A2B.2050701@goop.org>
	<20100615114543.644442a9@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <20100615114543.644442a9@mantra.us.oracle.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
List-Id: xen-devel@lists.xenproject.org

On Tue, 15 Jun 2010 11:45:43 -0700
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> On Tue, 15 Jun 2010 09:30:35 +0100
> Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> 
> > On 06/15/2010 03:49 AM, Mukesh Rathor wrote:
> > > On Mon, 14 Jun 2010 10:37:30 +0100
> > > Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> > >
> > >   
> > >> On 06/10/2010 03:13 AM, Mukesh Rathor wrote:
> > >>     
> > >>> Well, BUG_ON is only triggered if booting more than 32 VCPUs on
> > >>> a *very old* xen (pre xen 3.1.0). 
> > >>>
> > >>> Looking at code closely, we could just set setup_max_cpus to 32
> > >>> some where in xen function, perhaps even in xen_vcpu_setup().
> > >>> That way later in smp_init() it would just be ok. 
> > >>>   
> > >>>       
> > >> Yes.
> > >>
> > >>     
> > >>> One thing tho, the per cpus areas are already setup at that
> > >>> point, so that would need to be cleaned. BTW, I don't
> > >>> understand why have_vcpu_info_placement is set to 0 in
> > >>> xen_guest_init()? 
> > >>>       
> > >> xen_guest_init is used by the pvhvm path, and hvm domains don't
> > >> have a notion of vcpu info placement.
> > >>
> > >>     
> > >>> What minimum version of xen is required to run pvops kernel?
> > >>>   
> > >>>       
> > >> In theory it should be back-compatible for all Xen 3, but in
> > >> practice it tweaks lots of bugs in older Xens (particularly
> > >> 32-on-64).  I don't know that anyone has definitively established
> > >> an earliest version.  I implemented vcpu info placement for use
> > >> in pvops kernels, but it was never my intention that it be an
> > >> absolute requirement.
> > >>
> > >>     J
> > >>     
> > > Ok, attached  patch without BUG_ON. Please feel free to modify
> > > to your liking also.
> > >   
> > 
> > It looks like you smashed all the tabs into spaces so its hard to
> > see what you've changed in the diff.  I'll fix it up and give it a
> > look-over.
> > 
> >     J
> 
> Sorry, I've tabs turned off because patches I submit to other product
> I work on must be tab free.  Anyways, re attached a new one with tabs.
> 
> thanks again,
> Mukesh
> 
> Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>

Hi Jeremy,

Just curious, did this patch ever make it?

thanks
Mukesh