From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH V4 7/8] xen/arm64: increase MAX_VIRT_CPUS to 128 on arm64 Date: Fri, 29 May 2015 17:49:55 +0100 Message-ID: <556898B3.1050104@citrix.com> References: <1432808109-31466-1-git-send-email-cbz@baozis.org> <1432808109-31466-8-git-send-email-cbz@baozis.org> <55688B17.8040104@citrix.com> <556891D3.8040400@citrix.com> <556896CE.8050308@citrix.com> <55689794.9080000@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YyNTt-0006uy-HB for xen-devel@lists.xenproject.org; Fri, 29 May 2015 16:50:01 +0000 In-Reply-To: <55689794.9080000@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall , Chen Baozi , xen-devel@lists.xenproject.org Cc: Chen Baozi , Ian Campbell List-Id: xen-devel@lists.xenproject.org On 29/05/15 17:45, Julien Grall wrote: > On 29/05/15 17:41, Andrew Cooper wrote: >> On 29/05/15 17:20, Julien Grall wrote: >>> On 29/05/15 16:51, Julien Grall wrote: >>>>> diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h >>>>> index 3b23e05..817c216 100644 >>>>> --- a/xen/include/asm-arm/config.h >>>>> +++ b/xen/include/asm-arm/config.h >>>>> @@ -47,7 +47,11 @@ >>>>> #define NR_CPUS 128 >>>>> #endif >>>>> >>>>> +#ifdef CONFIG_ARM_64 >>>>> +#define MAX_VIRT_CPUS 128 >>>>> +#else >>>>> #define MAX_VIRT_CPUS 8 >>>>> +#endif >>> Looking to the last patch, the usage of MAX_VIRT_CPUS is now minimal. >>> Can't finish to replace MAX_VIRT_CPUS to another corresponding value and >>> drop the define? >> You cant drop MAX_VIRT_CPUS (I tried this when introducing >> max_domain_vcpus()). It is used for some conditional compilation in >> common code. > AFAICT only in the event channel code to avoid allocating memory when > less than 64 vCPU is used. Correct. > > Anyway, if we can drop it. I would add a check in domain_max_vcpus for > safety. It has a second use currently for auditing the dom0_max_vcpus parameter (for both x86 and ARM), but could easily be replaced with a max_domain_vcpus() call. ~Andrew