qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: mdroth@linux.vnet.ibm.com, aik@ozlabs.ru, agraf@suse.de,
	qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
	tyreld@linux.vnet.ibm.com, pbonzini@redhat.com,
	Igor Mammedov <imammedo@redhat.com>,
	nfont@linux.vnet.ibm.com, afaerber@suse.de,
	david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [PATCH v5 01/10] vl: Don't allow CPU toplogies with partially filled cores
Date: Wed, 2 Dec 2015 20:08:23 +0530	[thread overview]
Message-ID: <20151202143823.GC21491@in.ibm.com> (raw)
In-Reply-To: <20151202141459.GR23717@thinpad.lan.raisama.net>

On Wed, Dec 02, 2015 at 12:14:59PM -0200, Eduardo Habkost wrote:
> On Wed, Dec 02, 2015 at 02:52:39PM +0100, Igor Mammedov wrote:
> > On Fri, 20 Nov 2015 18:24:30 +0530
> > Bharata B Rao <bharata@linux.vnet.ibm.com> wrote:
> > 
> > > Prevent guests from booting with CPU topologies that have partially
> > > filled CPU cores or can result in partially filled CPU cores after
> > > CPU hotplug like
> > > 
> > > -smp 15,sockets=1,cores=4,threads=4,maxcpus=16 or
> > > -smp 15,sockets=1,cores=4,threads=4,maxcpus=17.
> > 
> > CCing Eduardo who might tell if it's ok wrt x86
> 
> I am always afraid of introducing fatal errors for configurations
> that are obviously wrong but may already exist in production (so
> it would prevent users from migrating existing VMs). But I am
> becoming more inclined to be a bit more aggressive and stop
> allowing these broken configurations.
> 
> But I would rewrite the error message, and just say that "cpus"
> and "maxcpus" must be multiples of "threads". It's easier to
> understand and explain than what "partially filled cores" mean.
> You don't need to mention "sockets" and "cores" in the error
> message, either.
> 
> Also, please print different error messages to indicate if
> "maxcpus" or "cpus" is the culprit.

Sure, makes it easier for the user.

> 
> What about (cpus % (cores * threads) != 0)? It would result in
> sockets with different numbers of cores. Should we allow that?

I had planned to prevent that and also

(max_cpus % (cores * threads) != 0) in the next iteration. Would be
good to know if enforcing such a condition would be acceptable.

> 
> The patch makes QEMU crash with the following command-line:
> 
>   $ qemu-system-x86_64 -smp 2,cores=2,sockets=2
>   Floating point exception (core dumped)
>   $
> 
> It can probably be solved by moving the check after
> smp_{cpus,cores,threads} are already set.

Oh yes, will fix in the next iteration.

Regards,
Bharata.

  reply	other threads:[~2015-12-02 14:39 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-20 12:54 [Qemu-devel] [PATCH v5 00/10] sPAPR CPU hotplug Bharata B Rao
2015-11-20 12:54 ` [Qemu-devel] [PATCH v5 01/10] vl: Don't allow CPU toplogies with partially filled cores Bharata B Rao
2015-12-01  0:37   ` David Gibson
2015-12-02  3:04     ` Bharata B Rao
2015-12-02 13:52   ` Igor Mammedov
2015-12-02 14:14     ` Eduardo Habkost
2015-12-02 14:38       ` Bharata B Rao [this message]
2015-12-02 15:19         ` Eduardo Habkost
2015-11-20 12:54 ` [Qemu-devel] [PATCH v5 02/10] exec: Remove cpu from cpus list during cpu_exec_exit() Bharata B Rao
2015-12-01  0:44   ` David Gibson
2015-12-02  3:47     ` Bharata B Rao
2015-11-20 12:54 ` [Qemu-devel] [PATCH v5 03/10] exec: Do vmstate unregistration from cpu_exec_exit() Bharata B Rao
2015-12-01  0:46   ` David Gibson
2015-11-20 12:54 ` [Qemu-devel] [PATCH v5 04/10] cpu: Reclaim vCPU objects Bharata B Rao
2015-11-30  7:30   ` Alexey Kardashevskiy
2015-12-02  3:50     ` Bharata B Rao
2015-12-01  0:55   ` David Gibson
2015-12-02  5:28     ` Bharata B Rao
2015-11-20 12:54 ` [Qemu-devel] [PATCH v5 05/10] cpu: Add a sync version of cpu_remove() Bharata B Rao
2015-12-01  0:57   ` David Gibson
2015-11-20 12:54 ` [Qemu-devel] [PATCH v5 06/10] xics_kvm: Add cpu_destroy method to XICS Bharata B Rao
2015-12-01  1:01   ` David Gibson
2015-12-02  5:45     ` Bharata B Rao
2015-11-20 12:54 ` [Qemu-devel] [PATCH v5 07/10] spapr: Enable CPU hotplug for pseries-2.5 and add CPU DRC DT entries Bharata B Rao
2015-12-01  1:06   ` David Gibson
2015-12-02  5:47     ` Bharata B Rao
2015-11-20 12:54 ` [Qemu-devel] [PATCH v5 08/10] spapr: CPU hotplug support Bharata B Rao
2015-12-01  1:30   ` David Gibson
2015-12-01  4:48     ` Bharata B Rao
2015-11-20 12:54 ` [Qemu-devel] [PATCH v5 09/10] spapr: CPU hot unplug support Bharata B Rao
2015-12-01  1:34   ` David Gibson
2015-12-02  5:49     ` Bharata B Rao
2015-11-20 12:54 ` [Qemu-devel] [PATCH v5 10/10] target-ppc: Enable CPU hotplug for POWER8 CPU family Bharata B Rao
2015-11-23 11:54 ` [Qemu-devel] [PATCH v5 00/10] sPAPR CPU hotplug Peter Krempa
2015-11-23 13:04   ` Christian Borntraeger
2015-12-01  1:43     ` David Gibson

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=20151202143823.GC21491@in.ibm.com \
    --to=bharata@linux.vnet.ibm.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=david@gibson.dropbear.id.au \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=nfont@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=tyreld@linux.vnet.ibm.com \
    /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).