qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 7/7] vl.c: Use MAX_CPUS macro instead of hard


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v3 7/7] vl.c: Use MAX_CPUS macro instead of hardcoded constant
Date: Fri, 14 Mar 2014 16:30:50 -0300
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Mar 14, 2014 at 08:11:50PM +0100, Laszlo Ersek wrote:
> On 03/14/14 19:52, Eduardo Habkost wrote:
> > Signed-off-by: Eduardo Habkost <address@hidden>
> > ---
> >  vl.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/vl.c b/vl.c
> > index 64b38a5..62cc734 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -1413,7 +1413,7 @@ static void smp_parse(QemuOpts *opts)
> >          max_cpus = smp_cpus;
> >      }
> >  
> > -    if (max_cpus > 255) {
> > +    if (max_cpus > MAX_CPUS) {
> >          fprintf(stderr, "Unsupported number of maxcpus\n");
> >          exit(1);
> >      }
> > 
> 
> $ git grep -e '255' --and -e cpus
> 
> hw/s390x/s390-virtio-ccw.c:    .max_cpus = 255,
> hw/s390x/s390-virtio.c:    .max_cpus = 255,
> include/hw/i386/pc.h:    .max_cpus = 255
> vl.c:    if (max_cpus > 255) {
> 
> I propose to fix those other tree occurrences as well. (I could be
> easily wrong of course!, I didn't investigate.)

We first need to find out the reason behind those machine-specific
limits. Maybe they can be removed (if they are all because of NUMA
and/or ACPI), or maybe they need to use another macro because there are
other limits in machine-specific code.

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]