All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Bharata B Rao <bharata@linux.vnet.ibm.com>
Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org, agraf@suse.de,
	borntraeger@de.ibm.com, pbonzini@redhat.com, imammedo@redhat.com,
	afaerber@suse.de, david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [RFC PATCH v0 1/9] vl: Don't allow CPU toplogies with partially filled cores
Date: Mon, 14 Dec 2015 15:37:52 -0200	[thread overview]
Message-ID: <20151214173752.GD3774@thinpad.lan.raisama.net> (raw)
In-Reply-To: <20151211032431.GB18759@in.ibm.com>

On Fri, Dec 11, 2015 at 08:54:31AM +0530, Bharata B Rao wrote:
> On Thu, Dec 10, 2015 at 10:25:28AM +0000, Daniel P. Berrange wrote:
> > On Thu, Dec 10, 2015 at 11:45:36AM +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 or
> > > 
> > > Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
> > > ---
> > >  vl.c | 13 +++++++++++++
> > >  1 file changed, 13 insertions(+)
> > > 
> > > diff --git a/vl.c b/vl.c
> > > index 525929b..e656f53 100644
> > > --- a/vl.c
> > > +++ b/vl.c
> > > @@ -1252,6 +1252,19 @@ static void smp_parse(QemuOpts *opts)
> > >          smp_cores = cores > 0 ? cores : 1;
> > >          smp_threads = threads > 0 ? threads : 1;
> > >  
> > > +        if (smp_cpus % smp_threads) {
> > > +            error_report("cpu topology: "
> > > +                         "smp_cpus (%u) should be multiple of threads (%u)",
> > > +                         smp_cpus, smp_threads);
> > > +            exit(1);
> > > +        }
> > > +
> > > +        if (max_cpus % smp_threads) {
> > > +            error_report("cpu topology: "
> > > +                         "maxcpus (%u) should be multiple of threads (%u)",
> > > +                         max_cpus, smp_threads);
> > > +            exit(1);
> > > +        }
> > >      }
> > 
> > Adding this seems like it has a pretty high chance of causing regression,
> > ie preventing previously working guests from booting with new QEMU. I
> > know adding the check makes sense from a semantic POV, but are we willing
> > to risk breaking people with such odd configurations ?
> 
> I wasn't sure about how much risk that would be and hence in my older
> version of PowerPC CPU hotplug patchset, I indeed supported such topologies:
> 
> https://lists.gnu.org/archive/html/qemu-ppc/2015-09/msg00102.html
> 
> But the code indeed looked ugly to support such special case.
> 
> There was some discussion about this recently here:
> 
> http://lists.gnu.org/archive/html/qemu-devel/2015-12/msg00396.html
> 
> from where I sensed that it may be ok to dis-allow such topologies.

I want to be as strict as possible and disallow such topologies,
but Daniel has a point. Maybe we should make those checks
machine-specific, so we can make pc-*-2.5 and older allow those
broken configs.

If we make it a MachineClass::validate_smp_config() method, for
example, we could make TYPE_MACHINE point to a generic function
containing the checks you implemented above (so all machines have
those checks enabled by default), but let pc <= 2.5 override the
method.

-- 
Eduardo

  reply	other threads:[~2015-12-14 17:37 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-10  6:15 [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 1/9] vl: Don't allow CPU toplogies with partially filled cores Bharata B Rao
2015-12-10 10:25   ` Daniel P. Berrange
2015-12-11  3:24     ` Bharata B Rao
2015-12-14 17:37       ` Eduardo Habkost [this message]
2015-12-15  8:41         ` Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState Bharata B Rao
2015-12-14 17:29   ` Eduardo Habkost
2015-12-15  8:38     ` Bharata B Rao
2015-12-15 15:31       ` Eduardo Habkost
2015-12-16 16:54       ` Igor Mammedov
2015-12-16 19:39         ` Eduardo Habkost
2015-12-16 22:26           ` Igor Mammedov
2015-12-17 18:09             ` Eduardo Habkost
2015-12-18 10:46               ` Igor Mammedov
2015-12-18 15:51                 ` Eduardo Habkost
2015-12-18 16:01                   ` Igor Mammedov
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 3/9] cpu: Don't realize CPU from cpu_generic_init() Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 4/9] cpu: CPU socket backend Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 5/9] vl: Create CPU socket backend objects Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 6/9] cpu: Introduce CPU core device Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 7/9] spapr: Convert boot CPUs into CPU core device initialization Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 8/9] target-i386: Set apic_id during CPU initfn Bharata B Rao
2015-12-14 17:44   ` Eduardo Habkost
2015-12-15  8:14     ` Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 9/9] pc: Convert boot CPUs into CPU core device initialization Bharata B Rao
2015-12-10 12:35 ` [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device Igor Mammedov
2015-12-11  3:57   ` Bharata B Rao
2015-12-15  5:27     ` Zhu Guihua
2015-12-16 15:16       ` Andreas Färber
2015-12-16 15:11     ` Igor Mammedov
2015-12-17  9:19       ` Peter Krempa
2015-12-16 15:46   ` Andreas Färber
2015-12-16 21:58     ` Igor Mammedov
2015-12-24  1:59       ` Zhu Guihua
2015-12-29 13:52         ` Igor Mammedov
2016-01-01  3:47     ` Bharata B Rao
2016-01-04 12:52       ` Igor Mammedov
2015-12-10 20:25 ` Matthew Rosato
2015-12-14  6:25   ` Bharata B Rao
2015-12-16 15:19 ` Andreas Färber
2015-12-16 15:44   ` Igor Mammedov
2015-12-16 15:57     ` Andreas Färber
2015-12-16 17:22       ` Igor Mammedov
2015-12-16 22:37         ` Igor Mammedov
2016-01-12  3:54         ` 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=20151214173752.GD3774@thinpad.lan.raisama.net \
    --to=ehabkost@redhat.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=imammedo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@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.