From: Zhao Liu <zhao1.liu@intel.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: "Daniel P . Berrang�" <berrange@redhat.com>,
"Igor Mammedov" <imammedo@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Philippe Mathieu-Daud�" <philmd@linaro.org>,
"Yanan Wang" <wangyanan55@huawei.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Sergio Lopez" <slp@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Anthony PERARD" <anthony@xenproject.org>,
"Paul Durrant" <paul@xen.org>,
"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
"Eric Blake" <eblake@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Alex Benn�e" <alex.bennee@linaro.org>,
"Peter Maydell" <peter.maydell@linaro.org>,
qemu-devel@nongnu.org, kvm@vger.kernel.org, qemu-arm@nongnu.org,
"Zhenyu Wang" <zhenyu.z.wang@intel.com>,
"Dapeng Mi" <dapeng1.mi@linux.intel.com>,
"Yongwei Ma" <yongwei.ma@intel.com>,
"Zhao Liu" <zhao1.liu@intel.com>
Subject: Re: [RFC v2 05/12] hw/core/machine: Introduce custom CPU topology with max limitations
Date: Wed, 9 Oct 2024 14:46:28 +0800 [thread overview]
Message-ID: <ZwYmxH8sl5v8ZpNZ@intel.com> (raw)
In-Reply-To: <20241008111651.000025ab@Huawei.com>
> A few code style comments inline.
>
> J
> > diff --git a/hw/cpu/cpu-slot.c b/hw/cpu/cpu-slot.c
> > index 1cc3b32ed675..2d16a2729501 100644
> > --- a/hw/cpu/cpu-slot.c
> > +++ b/hw/cpu/cpu-slot.c
>
> > +
> > +bool machine_parse_custom_topo_config(MachineState *ms,
> > + const SMPConfiguration *config,
> > + Error **errp)
> > +{
> > + MachineClass *mc = MACHINE_GET_CLASS(ms);
> > + CPUSlot *slot = ms->topo;
> > + bool is_valid;
> > + int maxcpus;
> > +
> > + if (!slot) {
> > + return true;
> > + }
> > +
> > + is_valid = config->has_maxsockets && config->maxsockets;
> > + if (mc->smp_props.custom_topo_supported) {
> > + slot->stat.entries[CPU_TOPOLOGY_LEVEL_SOCKET].max_limit =
> > + is_valid ? config->maxsockets : ms->smp.sockets;
> > + } else if (is_valid) {
> > + error_setg(errp, "maxsockets > 0 not supported "
> > + "by this machine's CPU topology");
> > + return false;
> > + } else {
> > + slot->stat.entries[CPU_TOPOLOGY_LEVEL_SOCKET].max_limit =
> > + ms->smp.sockets;
> > + }
> Having the error condition in the middle is rather confusing to
> read to my eyes. Playing with equivalents I wonder what works best..
Figuring out how to clearly express the logic here was indeed a bit of a
struggle for me at first. :-)
> if (!is_valid) {
> slot->stat.entries[CPU_TOPOLOGY_LEVEL_SOCKET].max_limit =
> ms->smp.sockets;
> } else if (mc->smp_props.custom_topo_supported) {
> slot->stat.entries[CPU_TOPOLOGY_LEVEL_SOCKET].max_limit =
> config->max_sockets;
> } else {
> error_setg...
> return false;
> }
>
> or take the bad case out first. Maybe this is a little obscure
> though (assuming I even got it right) as it relies on the fact
> that is_valid must be false for the legacy path.
>
> if (!mc->smp_props.custom_topo_supported && is_valid) {
> error_setg();
> return false;
> }
>
> slot->stat.entries[CPU_TOPOLOGY_LEVEL_SOCKET].max_limit =
> is_valid ? config->maxsockets : ms->smp.sockets;
>
> Similar for other cases.
I prefer the first style, as it's more natural and clear enough!
Many thanks!
[snip]
> > + maxcpus = 1;
> > + /* Initizlize max_limit to 1, as members of CpuTopology. */
> > + for (int i = 0; i < CPU_TOPOLOGY_LEVEL__MAX; i++) {
> > + maxcpus *= slot->stat.entries[i].max_limit;
> > + }
> > +
> > + if (!config->has_maxcpus) {
> > + ms->smp.max_cpus = maxcpus;
> Maybe early return here to get rid of need for the else?
Yes, it's better to reduce else.
> > + } else {
> > + if (maxcpus != ms->smp.max_cpus) {
>
> Unless this is going to get more complex later, else if probably appropriate here
> (if you don't drop the else above.
I can organize it like:
if (!config->has_maxcpus) {
...
return true;
}
if (maxcpus != ms->smp.max_cpus) {
error_steg...
return false;
}
return true;
As you suggested to get rid of a "else". :)
> > + error_setg(errp, "maxcpus (%d) should be equal to "
> > + "the product of the remaining max parameters (%d)",
> > + ms->smp.max_cpus, maxcpus);
> > + return false;
> > + }
> > + }
> > +
> > + return true;
> > +}
Regards,
Zhao
next prev parent reply other threads:[~2024-10-09 6:30 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-19 6:11 [RFC v2 00/12] Introduce Hybrid CPU Topology via Custom Topology Tree Zhao Liu
2024-09-19 6:11 ` [RFC v2 01/12] qdev: Allow qdev_device_add() to add specific category device Zhao Liu
2024-10-08 9:14 ` Jonathan Cameron
2024-10-08 9:14 ` Jonathan Cameron via
2024-10-09 6:09 ` Zhao Liu
2024-09-19 6:11 ` [RFC v2 02/12] qdev: Introduce new device category to cover basic topology device Zhao Liu
2024-09-19 6:11 ` [RFC v2 03/12] system/vl: Create CPU topology devices from CLI early Zhao Liu
2024-10-08 9:50 ` Jonathan Cameron
2024-10-08 9:50 ` Jonathan Cameron via
2024-10-09 6:31 ` Zhao Liu
2024-10-08 9:55 ` Jonathan Cameron
2024-10-08 9:55 ` Jonathan Cameron via
2024-10-09 6:11 ` Zhao Liu
2024-09-19 6:11 ` [RFC v2 04/12] hw/core/machine: Split machine initialization around qemu_add_cli_devices_early() Zhao Liu
2024-09-19 6:11 ` [RFC v2 05/12] hw/core/machine: Introduce custom CPU topology with max limitations Zhao Liu
2024-10-08 10:16 ` Jonathan Cameron
2024-10-08 10:16 ` Jonathan Cameron via
2024-10-09 6:46 ` Zhao Liu [this message]
2024-09-19 6:11 ` [RFC v2 06/12] hw/cpu: Constrain CPU topology tree with max_limit Zhao Liu
2024-09-19 6:11 ` [RFC v2 07/12] hw/core: Re-implement topology helpers to honor max limitations Zhao Liu
2024-09-19 6:11 ` [RFC v2 08/12] hw/i386: Use get_max_topo_by_level() to get topology information Zhao Liu
2024-09-19 6:11 ` [RFC v2 09/12] i386: Introduce x86 CPU core abstractions Zhao Liu
2024-09-19 6:11 ` [RFC v2 10/12] i386/cpu: Support Intel hybrid CPUID Zhao Liu
2024-09-19 6:11 ` [RFC v2 11/12] i386/machine: Split machine initialization after CPU creation into post_init() Zhao Liu
2024-09-19 6:11 ` [RFC v2 12/12] i386: Support custom topology for microvm, pc-i440fx and pc-q35 Zhao Liu
2024-10-08 10:30 ` [RFC v2 00/12] Introduce Hybrid CPU Topology via Custom Topology Tree Jonathan Cameron
2024-10-08 10:30 ` Jonathan Cameron via
2024-10-09 6:01 ` Zhao Liu
2024-10-09 6:51 ` 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=ZwYmxH8sl5v8ZpNZ@intel.com \
--to=zhao1.liu@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=alex.bennee@linaro.org \
--cc=anthony@xenproject.org \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=eblake@redhat.com \
--cc=edgar.iglesias@gmail.com \
--cc=eduardo@habkost.net \
--cc=imammedo@redhat.com \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=slp@redhat.com \
--cc=sstabellini@kernel.org \
--cc=wangyanan55@huawei.com \
--cc=yongwei.ma@intel.com \
--cc=zhenyu.z.wang@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 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.