All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	"Daniel P . Berrange" <berrange@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Yanan Wang <wangyanan55@huawei.com>
Subject: Re: [PULL 1/1] machine: Disallow specifying topology parameters as zero
Date: Tue, 17 Aug 2021 14:02:50 +0200	[thread overview]
Message-ID: <20210817120250.fdpujloefaqtawwo@gator.home> (raw)
In-Reply-To: <CABgObfaWxNsq2i8j6P+oZGFjxyR3MFE9FopHsnvuNAPXa4upYQ@mail.gmail.com>

On Mon, Aug 16, 2021 at 11:37:21PM +0200, Paolo Bonzini wrote:
> How do we know that no one has ever used such configuration? The conversion
> was meant to be bug-compatible.

We don't. But we do know that a zero input value was never documented
prior to 1e63fe68580, which has not yet been released. Can we claim
that an undocumented input value has undefined behavior, giving us
freedom to modify that behavior until it is documented?

Thanks,
drew

> 
> Paolo
> 
> Il lun 16 ago 2021, 23:06 Eduardo Habkost <ehabkost@redhat.com> ha scritto:
> 
> > From: Yanan Wang <wangyanan55@huawei.com>
> >
> > In the SMP configuration, we should either provide a topology
> > parameter with a reasonable value (greater than zero) or just
> > omit it and QEMU will compute the missing value. Users should
> > have never provided a configuration with parameters as zero
> > (e.g. -smp 8,sockets=0) which should be treated as invalid.
> >
> > But commit 1e63fe68580 (machine: pass QAPI struct to mc->smp_parse)
> > has added some doc which implied that 'anything=0' is valid and
> > has the same semantics as omitting a parameter.
> >
> > To avoid meaningless configurations possibly introduced by users
> > in the future and consequently a necessary deprecation process,
> > fix the doc and also add the corresponding sanity check.
> >
> > Fixes: 1e63fe68580 (machine: pass QAPI struct to mc->smp_parse)
> > Suggested-by: Andrew Jones <drjones@redhat.com>
> > Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
> > Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
> > Tested-by: Daniel P. Berrange <berrange@redhat.com>
> > Reviewed-by: Andrew Jones <drjones@redhat.com>
> > Reviewed-by: Cornelia Huck <cohuck@redhat.com>
> > Message-Id: <20210816024522.143124-2-wangyanan55@huawei.com>
> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > ---
> >  hw/core/machine.c | 14 ++++++++++++++
> >  qapi/machine.json |  6 +++---
> >  qemu-options.hx   | 12 +++++++-----
> >  3 files changed, 24 insertions(+), 8 deletions(-)
> >
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index 54e040587dd..a7e119469aa 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -832,6 +832,20 @@ static void machine_set_smp(Object *obj, Visitor *v,
> > const char *name,
> >          return;
> >      }
> >
> > +    /*
> > +     * A specified topology parameter must be greater than zero,
> > +     * explicit configuration like "cpus=0" is not allowed.
> > +     */
> > +    if ((config->has_cpus && config->cpus == 0) ||
> > +        (config->has_sockets && config->sockets == 0) ||
> > +        (config->has_dies && config->dies == 0) ||
> > +        (config->has_cores && config->cores == 0) ||
> > +        (config->has_threads && config->threads == 0) ||
> > +        (config->has_maxcpus && config->maxcpus == 0)) {
> > +        error_setg(errp, "CPU topology parameters must be greater than
> > zero");
> > +        goto out_free;
> > +    }
> > +
> >      mc->smp_parse(ms, config, errp);
> >      if (*errp) {
> >          goto out_free;
> > diff --git a/qapi/machine.json b/qapi/machine.json
> > index c3210ee1fb2..9272cb3cf8b 100644
> > --- a/qapi/machine.json
> > +++ b/qapi/machine.json
> > @@ -1288,8 +1288,8 @@
> >  ##
> >  # @SMPConfiguration:
> >  #
> > -# Schema for CPU topology configuration.  "0" or a missing value lets
> > -# QEMU figure out a suitable value based on the ones that are provided.
> > +# Schema for CPU topology configuration. A missing value lets QEMU
> > +# figure out a suitable value based on the ones that are provided.
> >  #
> >  # @cpus: number of virtual CPUs in the virtual machine
> >  #
> > @@ -1297,7 +1297,7 @@
> >  #
> >  # @dies: number of dies per socket in the CPU topology
> >  #
> > -# @cores: number of cores per thread in the CPU topology
> > +# @cores: number of cores per die in the CPU topology
> >  #
> >  # @threads: number of threads per core in the CPU topology
> >  #
> > diff --git a/qemu-options.hx b/qemu-options.hx
> > index 83aa59a920f..aee622f577d 100644
> > --- a/qemu-options.hx
> > +++ b/qemu-options.hx
> > @@ -227,11 +227,13 @@ SRST
> >      of computing the CPU maximum count.
> >
> >      Either the initial CPU count, or at least one of the topology
> > parameters
> > -    must be specified. Values for any omitted parameters will be computed
> > -    from those which are given. Historically preference was given to the
> > -    coarsest topology parameters when computing missing values (ie sockets
> > -    preferred over cores, which were preferred over threads), however,
> > this
> > -    behaviour is considered liable to change.
> > +    must be specified. The specified parameters must be greater than zero,
> > +    explicit configuration like "cpus=0" is not allowed. Values for any
> > +    omitted parameters will be computed from those which are given.
> > +    Historically preference was given to the coarsest topology parameters
> > +    when computing missing values (ie sockets preferred over cores, which
> > +    were preferred over threads), however, this behaviour is considered
> > +    liable to change.
> >  ERST
> >
> >  DEF("numa", HAS_ARG, QEMU_OPTION_numa,
> > --
> > 2.31.1
> >
> >



  reply	other threads:[~2021-08-17 12:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-16 21:06 [PULL 0/1] Last minute fix for -rc4 Eduardo Habkost
2021-08-16 21:06 ` [PULL 1/1] machine: Disallow specifying topology parameters as zero Eduardo Habkost
2021-08-16 21:37   ` Paolo Bonzini
2021-08-17 12:02     ` Andrew Jones [this message]
2021-08-17 12:06       ` Peter Maydell
2021-08-17 12:22         ` Andrew Jones
2021-08-17 12:37           ` Peter Maydell
2021-08-17 12:54             ` Andrew Jones
2021-08-17 13:29           ` wangyanan (Y)
2021-08-16 21:38 ` [PULL 0/1] Last minute fix for -rc4 Paolo Bonzini

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=20210817120250.fdpujloefaqtawwo@gator.home \
    --to=drjones@redhat.com \
    --cc=berrange@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=wangyanan55@huawei.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.