qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Zhao Liu <zhao1.liu@linux.intel.com>
To: Prasad Pandit <ppandit@redhat.com>
Cc: "Thomas Huth" <thuth@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Yanan Wang" <wangyanan55@huawei.com>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Igor Mammedov" <imammedo@redhat.com>,
	qemu-devel@nongnu.org, "Xiaoling Song" <xiaoling.song@intel.com>,
	"Zhao Liu" <zhao1.liu@intel.com>,
	"Prasad Pandit" <pjp@fedoraproject.org>
Subject: Re: [PATCH 03/14] hw/core/machine-smp: Simplify variables' initialization in machine_parse_smp_config()
Date: Mon, 11 Mar 2024 13:20:24 +0800	[thread overview]
Message-ID: <Ze6UmDoFD5Qd8AC/@intel.com> (raw)
In-Reply-To: <CAE8KmOxHNTGkE-8Xd+RXOuHNmyHqPwU4HcYRO6qHBGVAy6nAew@mail.gmail.com>

Hi Prasad (and also welcome folks correct me),

> On Fri, 8 Mar 2024 at 20:50, Zhao Liu <zhao1.liu@linux.intel.com> wrote:
> > On Fri, Mar 08, 2024 at 02:20:45PM +0100, Thomas Huth wrote:
> > > Can we always rely on that? ... or is this just by luck due to the current
> > > implementation? In the latter case, I'd maybe rather drop this patch again.
> >
> > Thanks for the correction, I revisited and referenced more similar use
> > cases, and indeed, only if the flag "has_*" is true, its corresponding
> > field should be considered reliable.
> 
> * Is this because 'SMPConfiguration config'  fields are not always
> initialized with default values?

SMPConfiguration is created and set in machine_set_smp().

Firstly, it is created by g_autoptr(), and then it is initialized by
visit_type_SMPConfiguration().

The visit_type_SMPConfiguration() is generated by
gen_visit_object_members() in scripts/qapi/visit.py.

The g_autoptr() requires user to initialize:

  You must initialise the variable in some way — either by use of an
  initialiser or by ensuring that it is assigned to unconditionally
  before it goes out of scope.

This means if user doesn't initialize some field, the the value should
be considerred as unreliable. And I guess for int, the default
initialization value is the same as if we had declared a regular integer
variable. But anyway, fields that are not explicitly initialized should
not be accessed.

IIUC, in visit_type_SMPConfiguration() (let's have a look at
gen_visit_object_members()), there's no explicit initialization of
SMPConfiguration() (i.e., the parameter named "%(c_name)s *obj" in
gen_visit_object_members()). For int type, has_* means that the field is
set.

Therefore, we shouldn't rely on the uninitialized fields and should
check the has_*.

> Is that a bug?

It's not a bug, and it could be a simplification of the automatic code
generation.

> Having 'SMPConfiguration' fields initialised to known default values could
> help to unify/simplify code which uses those fields.

I realized that keeping the check for has_* here would help improve code
readability; after all, it's more of a pain to go back and check
scripts.

> > Keeping explicit checking on has_* and explicit initialization of these
> > topology variables makes the code more readable.
> >
> > This patch is over-optimized and I would drop it.
> 
> * Could we then simplify it in the following if <expression>
> ===
>       if ((config->has_cpus && config->cpus == 0) ||
>           ... ||
>           (config->has_maxcpus && config->maxcpus == 0))
> 
> could be
> 
>       if (!cpus || !drawers || ... || !maxcpus) { ... }
> ===
>

This doesn't work since the above check is used to identify if user sets
parameters as 0 explicitly, which needs to check both has_* and the
specific field value.

(Communicating with you also helped me to understand the QAPI related
parts.)

Thanks,
Zhao




  reply	other threads:[~2024-03-11  5:07 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06  9:53 [PATCH 00/14] Cleanup on SMP and its test Zhao Liu
2024-03-06  9:53 ` [PATCH 01/14] hw/core/machine-smp: Remove deprecated "parameter=0" SMP configurations Zhao Liu
2024-03-06  9:53 ` [PATCH 02/14] hw/core/machine-smp: Deprecate unsupported "parameter=1" " Zhao Liu
2024-03-07  6:22   ` Thomas Huth
2024-03-07  7:07     ` Zhao Liu
2024-03-06  9:53 ` [PATCH 03/14] hw/core/machine-smp: Simplify variables' initialization in machine_parse_smp_config() Zhao Liu
2024-03-08 13:20   ` Thomas Huth
2024-03-08 15:33     ` Zhao Liu
2024-03-10 11:55       ` Prasad Pandit
2024-03-11  5:20         ` Zhao Liu [this message]
2024-03-13 10:52           ` Prasad Pandit
2024-03-18  8:06             ` Zhao Liu
2024-03-18 11:18               ` Prasad Pandit
2024-03-06  9:53 ` [PATCH 04/14] hw/core/machine-smp: Calculate total CPUs once " Zhao Liu
2024-03-06 20:56   ` Philippe Mathieu-Daudé
2024-03-06  9:53 ` [PATCH 05/14] tests/unit/test-smp-parse: Drop the unsupported "dies=1" case Zhao Liu
2024-03-08 13:22   ` Thomas Huth
2024-03-06  9:53 ` [PATCH 06/14] tests/unit/test-smp-parse: Use CPU number macros in invalid topology case Zhao Liu
2024-03-06  9:54 ` [PATCH 07/14] tests/unit/test-smp-parse: Bump max_cpus to 4096 Zhao Liu
2024-03-07  6:01   ` Thomas Huth
2024-03-07  7:03     ` Zhao Liu
2024-03-06  9:54 ` [PATCH 08/14] tests/unit/test-smp-parse: Make test cases aware of the book/drawer Zhao Liu
2024-03-06  9:54 ` [PATCH 09/14] tests/unit/test-smp-parse: Test "books" parameter in -smp Zhao Liu
2024-03-06  9:54 ` [PATCH 10/14] tests/unit/test-smp-parse: Test "drawers" " Zhao Liu
2024-03-06  9:54 ` [PATCH 11/14] tests/unit/test-smp-parse: Test "drawers" and "books" combination case Zhao Liu
2024-03-07  6:07   ` Thomas Huth
2024-03-06  9:54 ` [PATCH 12/14] tests/unit/test-smp-parse: Test the full 7-levels topology hierarchy Zhao Liu
2024-03-06  9:54 ` [PATCH 13/14] tests/unit/test-smp-parse: Test smp_props.has_clusters Zhao Liu
2024-03-06  9:54 ` [PATCH 14/14] tests/unit/test-smp-parse: Test "parameter=0" SMP configurations Zhao Liu
2024-03-07  6:11   ` Thomas Huth
2024-03-06 21:07 ` [PATCH 00/14] Cleanup on SMP and its test Philippe Mathieu-Daudé
2024-03-07  7:25   ` Zhao Liu

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=Ze6UmDoFD5Qd8AC/@intel.com \
    --to=zhao1.liu@linux.intel.com \
    --cc=berrange@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=imammedo@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=philmd@linaro.org \
    --cc=pjp@fedoraproject.org \
    --cc=ppandit@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=wangyanan55@huawei.com \
    --cc=xiaoling.song@intel.com \
    --cc=zhao1.liu@intel.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).