From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:34321)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Vjnmv-0006gX-Ck
	for qemu-devel@nongnu.org; Fri, 22 Nov 2013 05:16:43 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Vjnmp-00033y-Du
	for qemu-devel@nongnu.org; Fri, 22 Nov 2013 05:16:37 -0500
Received: from mx1.redhat.com ([209.132.183.28]:5908)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Vjnmp-00033g-6e
	for qemu-devel@nongnu.org; Fri, 22 Nov 2013 05:16:31 -0500
Message-ID: <528F2EF8.9090509@redhat.com>
Date: Fri, 22 Nov 2013 11:16:24 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1385044625-31006-1-git-send-email-pl@kamp.de>
In-Reply-To: <1385044625-31006-1-git-send-email-pl@kamp.de>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] vl: verify if combination of cpus, sockets,
 cores and threads is sane
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Lieven <pl@kamp.de>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org

Il 21/11/2013 15:37, Peter Lieven ha scritto:
> -        max_cpus = qemu_opt_get_number(opts, "maxcpus", 0);
> +        if (cpus != sockets * cores * threads) {
> +            fprintf(stderr, "Illegal CPU layout: %d cpus with %d sockets,"
> +                            " %d cores per socket and %d threads per core"
> +                            " (cpus != sockets * cores * threads)\n",
> +                            cpus, sockets, cores, threads);
> +            exit(1);
> +        }

Should max_cpus be checked instead if non-zero?

I see where you come from, but I think the potential for this patch to
break some working configuration (for some definition of working) is too
high.  Can you split out the fixes to the "fill in the blanks" logic?

Paolo