qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: "Eduardo Habkost" <ehabkost@redhat.com>,
	"Andreas Färber" <afaerber@suse.de>
Cc: qemu-trivial@nongnu.org, Igor Mammedov <imammedo@redhat.com>,
	Michael Tokarev <mjt@tls.msk.ru>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-trivial] [PATCH] vl: remove (max_cpus > 255) check from smp_parse
Date: Wed, 04 Dec 2013 16:50:59 +1100	[thread overview]
Message-ID: <529EC2C3.3050703@ozlabs.ru> (raw)
In-Reply-To: <20131203144740.GL22837@otherpad.lan.raisama.net>

On 12/04/2013 01:47 AM, Eduardo Habkost wrote:
> 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.


Since smp_parse() checks if (max_cpus >= smp_cpus), this should just work:

diff --git a/vl.c b/vl.c
index e6ed260..544165a 100644
--- a/vl.c
+++ b/vl.c
@@ -3882,9 +3882,9 @@ int main(int argc, char **argv, char **envp)
     smp_parse(qemu_opts_find(qemu_find_opts("smp-opts"), NULL));

     machine->max_cpus = machine->max_cpus ?: 1; /* Default to UP */
-    if (smp_cpus > machine->max_cpus) {
+    if (max_cpus > machine->max_cpus) {
         fprintf(stderr, "Number of SMP cpus requested (%d), exceeds max cpus "
-                "supported by machine `%s' (%d)\n", smp_cpus,  machine->name,
+                "supported by machine `%s' (%d)\n", max_cpus,  machine->name,
                 machine->max_cpus);
         exit(1);
     }


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


Nope. At the moment when we parse -numa in vl.c, we may not know yet what
machine is going to be used and machines can have different max_cpus.

For now, I would simply change MAX_CPUMASK_BITS to something crazy, like
16384 (2KB per numa node), I hope QEMU can survive such a memory waste :)

Ok?


-- 
Alexey

  reply	other threads:[~2013-12-04  5:51 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
2013-12-04  5:50           ` Alexey Kardashevskiy [this message]
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=529EC2C3.3050703@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=afaerber@suse.de \
    --cc=ehabkost@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).