From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCHEs]: support more than 32 VCPUs in guests Date: Wed, 09 Jun 2010 17:49:52 -0700 Message-ID: <4C1036B0.4060905@goop.org> References: <20100609160920.1445fbbe@mantra.us.oracle.com> <4C102742.3010108@goop.org> <20100609170825.06a67ff9@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: <20100609170825.06a67ff9@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@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org 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