All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: mjrosato@linux.vnet.ibm.com, qemu-devel@nongnu.org,
	mdroth@linux.vnet.ibm.com, agraf@suse.de, aik@ozlabs.ru,
	pbonzini@redhat.com, qemu-ppc@nongnu.org,
	tyreld@linux.vnet.ibm.com,
	Bharata B Rao <bharata@linux.vnet.ibm.com>,
	nfont@linux.vnet.ibm.com, afaerber@suse.de,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH v7 01/13] machine: Don't allow CPU toplogies with partially filled cores
Date: Fri, 29 Jan 2016 13:36:05 -0200	[thread overview]
Message-ID: <20160129153605.GA3869@thinpad.lan.raisama.net> (raw)
In-Reply-To: <20160129161047.426c3d8f@nial.brq.redhat.com>

On Fri, Jan 29, 2016 at 04:10:47PM +0100, Igor Mammedov wrote:
> On Fri, 29 Jan 2016 12:24:18 -0200
> Eduardo Habkost <ehabkost@redhat.com> wrote:
> 
> > On Fri, Jan 29, 2016 at 02:52:30PM +1100, David Gibson wrote:
> > > On Thu, Jan 28, 2016 at 11:19:43AM +0530, Bharata B Rao 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.
> > > > 
> > > > This is enforced by introducing MachineClass::validate_smp_config()
> > > > that gets called from generic SMP parsing code. Machine type versions
> > > > that want to enforce this can define this to the generic version
> > > > provided.
> > > > 
> > > > Only sPAPR and PC machine types starting from version 2.6 enforce this in
> > > > this patch.
> > > > 
> > > > Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>  
> > > 
> > > I've been kind of lost in the back and forth about
> > > threads/cores/sockets.
> > > 
> > > What, in the end, is the rationale for allowing partially filled
> > > sockets, but not partially filled cores?  
> > 
> > I don't think there's a good reason for that (at least for PC).
> > 
> > It's easier to relax the requirements later if necessary, than
> > dealing with compatibility issues again when making the code more
> > strict. So I suggest we make validate_smp_config_generic() also
> > check if smp_cpus % (smp_threads * smp_cores) == 0.
> 
> that would break exiting setups.

Not if we do that only on newer machine classes.
validate_smp_config_generic() will be used only on *-2.6 and
newer.


> 
> Also in case of cpu hotplug this patch will break migration
> as target QEMU might refuse starting with hotplugged CPU thread.

This won't change older machine-types.

But I think you are right: it can break migration on pc-2.6, too.
But: isn't migration already broken when creating other sets of
CPUs that can't represented using -smp?

How exactly would you migrate a machine today, if you run:

  $ qemu-system-x86_64 -smp 16,sockets=2,cores=2,threads=2,maxcpus=32
  (QMP) cpu-add id=31


> 
> Perhaps this check should be enforced per target/machine if
> arch requires it.

It is. Please see the patch. It introduces a validate_smp_config
method.

But we need your input to clarify if
validate_smp_config_generic() is safe for pc-2.6 too.

-- 
Eduardo

  reply	other threads:[~2016-01-29 15:36 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-28  5:49 [Qemu-devel] [PATCH v7 00/13] sPAPR CPU hotplug Bharata B Rao
2016-01-28  5:49 ` [Qemu-devel] [PATCH v7 01/13] machine: Don't allow CPU toplogies with partially filled cores Bharata B Rao
2016-01-28 19:04   ` Eduardo Habkost
2016-01-29  3:52   ` David Gibson
2016-01-29 14:24     ` Eduardo Habkost
2016-01-29 15:10       ` Igor Mammedov
2016-01-29 15:36         ` Eduardo Habkost [this message]
2016-01-29 16:52           ` Igor Mammedov
2016-01-29 17:24             ` Eduardo Habkost
2016-02-01  9:41               ` Igor Mammedov
2016-02-03 17:38                 ` Eduardo Habkost
2016-02-04  9:38                   ` Igor Mammedov
2016-01-28  5:49 ` [Qemu-devel] [PATCH v7 02/13] exec: Remove cpu from cpus list during cpu_exec_exit() Bharata B Rao
2016-01-28 19:19   ` Eduardo Habkost
2016-01-29  6:14     ` Bharata B Rao
2016-01-28  5:49 ` [Qemu-devel] [PATCH v7 03/13] exec: Do vmstate unregistration from cpu_exec_exit() Bharata B Rao
2016-01-28  5:49 ` [Qemu-devel] [PATCH v7 04/13] cpu: Don't realize CPU from cpu_generic_init() Bharata B Rao
2016-01-28  5:49 ` [Qemu-devel] [PATCH v7 05/13] cpu: Reclaim vCPU objects Bharata B Rao
2016-02-19 15:21   ` Thomas Huth
2016-01-28  5:49 ` [Qemu-devel] [PATCH v7 06/13] cpu: Add a sync version of cpu_remove() Bharata B Rao
2016-01-28  5:49 ` [Qemu-devel] [PATCH v7 07/13] xics, xics_kvm: Handle CPU unplug correctly Bharata B Rao
2016-01-28  5:49 ` [Qemu-devel] [PATCH v7 08/13] target-ppc: Introduce PowerPC specific CPU core device Bharata B Rao
2016-02-01  2:39   ` David Gibson
2016-01-28  5:49 ` [Qemu-devel] [PATCH v7 09/13] spapr: Enable CPU hotplug for pseries-2.6 and add CPU DRC DT entries Bharata B Rao
2016-01-28  5:49 ` [Qemu-devel] [PATCH v7 10/13] spapr: CPU hotplug support Bharata B Rao
2016-02-01  3:07   ` David Gibson
2016-01-28  5:49 ` [Qemu-devel] [PATCH v7 11/13] spapr: CPU hot unplug support Bharata B Rao
2016-02-01  3:13   ` David Gibson
2016-01-28  5:49 ` [Qemu-devel] [PATCH v7 12/13] qmp: Add query-ppc-cpu-cores command Bharata B Rao
2016-01-28 20:52   ` Eric Blake
2016-01-29  6:34     ` Bharata B Rao
2016-01-29 15:45   ` Igor Mammedov
2016-02-01  8:43     ` Bharata B Rao
2016-02-01  9:56       ` Igor Mammedov
2016-01-28  5:49 ` [Qemu-devel] [PATCH v7 13/13] hmp: Add "info ppc-cpu-cores" command Bharata B Rao
2016-01-28 21:56   ` Eric Blake
2016-01-29  6:49     ` Bharata B Rao

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=20160129153605.GA3869@thinpad.lan.raisama.net \
    --to=ehabkost@redhat.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=imammedo@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=mjrosato@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 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.