WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCHEs]: support more than 32 VCPUs in guests
From: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
Date: Wed, 9 Jun 2010 19:13:32 -0700
Cc: Jan, "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 09 Jun 2010 19:16:32 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C1036B0.4060905@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Oracle Corporation
References: <20100609160920.1445fbbe@xxxxxxxxxxxxxxxxxxxx> <4C102742.3010108@xxxxxxxx> <20100609170825.06a67ff9@xxxxxxxxxxxxxxxxxxxx> <4C1036B0.4060905@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, 09 Jun 2010 17:49:52 -0700
Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:

> On 06/09/2010 05:08 PM, Mukesh Rathor wrote:
> >> Why BUG_ON if the number of cpus is too high?  Why not just ignore
> >> the excess ones?
> >>     
> > Yeah, that was my first thought also... but then i realized i
> > couldn't just ignore the excess cpus in that function, but would
> > need to go back and fixup all the cpu_present, cpu_online, etc maps
> > (and any assoc data structs, if any), and it just didn't seem worth
> > it in the 2.6.18* kernels at least. Would have been easier to do if
> > the vcpu setup function returned a value instead of being void. 
> >   
> 
> Yes, but if have_vcpu_info_placement ends up being false (which is
> tested before any other cpus are brought up) then you can simply fail
> to online the ones above the limit.
> 
> BUG_ON is way too brutal.  You need to fail more softly.
> 
>     J

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. 
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()? 

What minimum version of xen is required to run pvops kernel?

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel