Re: [PATCHEs]: support more than 32 VCPUs in guests

[Mukesh Rathor <mukesh.rathor@oracle.com>]

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