All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: "Andreas Färber" <afaerber@suse.de>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
	qemu-trivial@nongnu.org, Michael Tokarev <mjt@tls.msk.ru>,
	qemu-devel@nongnu.org, Igor Mammedov <imammedo@redhat.com>
Subject: Re: [Qemu-devel] [Qemu-trivial] [PATCH] vl: remove (max_cpus > 255) check from smp_parse
Date: Tue, 3 Dec 2013 12:47:40 -0200	[thread overview]
Message-ID: <20131203144740.GL22837@otherpad.lan.raisama.net> (raw)
In-Reply-To: <529DDD08.4030206@suse.de>

On Tue, Dec 03, 2013 at 02:30:48PM +0100, Andreas Färber wrote:
> Am 03.12.2013 00:03, schrieb Alexey Kardashevskiy:
> > On 12/03/2013 09:09 AM, Andreas Färber wrote:
> >> Am 02.12.2013 18:06, schrieb Michael Tokarev:
> >>> 25.11.2013 07:39, Alexey Kardashevskiy wrote:
> >>>> Since modern POWER7/POWER8 chips can have more that 256 CPU threads
> >>>> (>2000 actually), remove this check from smp_parse.
> >>>>
> >>>> The CPUs number is still checked against machine->max_cpus and this check
> >>>> should be enough not to break other archs.
> >>
> >> "should be" is not exactly the highest level of confidence for a
> >> "trivial" patch... :/
> [...]
> >> Alexey, did you actually check that, e.g., x86 machines don't break with
> >> 256 or 257 CPUs now?
> > 
> > PC_DEFAULT_MACHINE_OPTIONS sets it to 255. And I cannot find any machine
> > which would not define max_cpus, have I missed any?
> 
> If you've actually *checked* the other machines' code then fine with me,
> just say so in the commit message. :)

I just grepped for "max_cpus" and checked every match. The largest
values I found were:

hw/ppc/spapr.c: 256
s390: 255
pc: 255

All the rest had values <= 32.

Machines with missing max_cpus value shouldn't be a problem, as
max_cpus==0 is interpreted as 1 by the vl.c code.

But we still need to add a check for max_cpus > machine->max_cpus to
vl.c, before we eliminate the smp_parse() check.

There's also this, at main():

        if (i == nb_numa_nodes) {
            for (i = 0; i < max_cpus; i++) {
                set_bit(i, node_cpumask[i % nb_numa_nodes]);
            }
        }

node_cpumask[] is initialized using bitmap_new(MAX_CPUMASK_BITS), and
MAX_CPUMASK_BITS is 255. To fix this, we can initialize node_cpumask[] using
max_cpus instead, if we initialize it after smp_parse().

-- 
Eduardo

  reply	other threads:[~2013-12-03 14:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-25  3:39 [Qemu-devel] [PATCH] vl: remove (max_cpus > 255) check from smp_parse Alexey Kardashevskiy
2013-12-02 17:06 ` [Qemu-devel] [Qemu-trivial] " Michael Tokarev
2013-12-02 22:09   ` Andreas Färber
2013-12-02 23:03     ` Alexey Kardashevskiy
2013-12-03  9:00       ` Markus Armbruster
2013-12-03 13:30       ` Andreas Färber
2013-12-03 14:47         ` Eduardo Habkost [this message]
2013-12-04  5:50           ` Alexey Kardashevskiy
2013-12-04 12:48             ` Eduardo Habkost
2014-02-14  6:56               ` Alexey Kardashevskiy
2014-02-14  7:34                 ` Paolo Bonzini
2013-12-03 10:44     ` Igor Mammedov
2013-12-03 14:33       ` Eduardo Habkost

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131203144740.GL22837@otherpad.lan.raisama.net \
    --to=ehabkost@redhat.com \
    --cc=afaerber@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=imammedo@redhat.com \
    --cc=mjt@tls.msk.ru \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.