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

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

On Fri, 16 Jul 2010 18:09:44 -0700
Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> On 07/16/2010 06:06 PM, Mukesh Rathor wrote:
> > 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?
> >   
> 
> Probably not.  Looks like I forgot to tag it as "mail containing
> patch" so it fell through the cracks.
>    
>     J

Did you want me to resubmit it, or can you find the patch?

thanks,
m