From: Tao Xu <tao3.xu@intel.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Radoslaw Biernacki <radoslaw.biernacki@linaro.org>,
Eduardo Habkost <ehabkost@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Leif Lindholm <leif.lindholm@linaro.org>,
"qemu-stable@nongnu.org" <qemu-stable@nongnu.org>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>
Subject: Re: [PATCH 2/2] numa: properly check if numa is supported
Date: Mon, 16 Dec 2019 09:03:30 +0800 [thread overview]
Message-ID: <a0e52b4d-d6b9-3dec-35b8-a3225f07d8d5@intel.com> (raw)
In-Reply-To: <20191213101219.0aa249dc@redhat.com>
On 12/13/2019 5:12 PM, Igor Mammedov wrote:
> On Fri, 13 Dec 2019 09:33:10 +0800
> Tao Xu <tao3.xu@intel.com> wrote:
>
>> On 12/12/2019 8:48 PM, Igor Mammedov wrote:
>>> Commit aa57020774b, by mistake used MachineClass::numa_mem_supported
>>> to check if NUMA is supported by machine and also as unrelated change
>>> set it to true for sbsa-ref board.
>>>
>>> Luckily change didn't break machines that support NUMA, as the field
>>> is set to true for them.
>>>
>>> But the field is not intended for checking if NUMA is supported and
>>> will be flipped to false within this release for new machine types.
>>>
>>> Fix it:
>>> - by using previously used condition
>>> !mc->cpu_index_to_instance_props || !mc->get_default_cpu_node_id
>>> the first time and then use MachineState::numa_state down the road
>>> to check if NUMA is supported
>>> - dropping stray sbsa-ref chunk
>>>
>>> Fixes: aa57020774b690a22be72453b8e91c9b5a68c516
>>> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
>>> ---
>>> CC: Radoslaw Biernacki <radoslaw.biernacki@linaro.org>
>>> CC: Peter Maydell <peter.maydell@linaro.org>
>>> CC: Leif Lindholm <leif.lindholm@linaro.org>
>>> CC: qemu-arm@nongnu.org
>>> CC: qemu-stable@nongnu.org
>>>
>>>
>>> hw/arm/sbsa-ref.c | 1 -
>>> hw/core/machine.c | 4 ++--
>>> 2 files changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
>>> index 27046cc..c6261d4 100644
>>> --- a/hw/arm/sbsa-ref.c
>>> +++ b/hw/arm/sbsa-ref.c
>>> @@ -791,7 +791,6 @@ static void sbsa_ref_class_init(ObjectClass *oc, void *data)
>>> mc->possible_cpu_arch_ids = sbsa_ref_possible_cpu_arch_ids;
>>> mc->cpu_index_to_instance_props = sbsa_ref_cpu_index_to_props;
>>> mc->get_default_cpu_node_id = sbsa_ref_get_default_cpu_node_id;
>>> - mc->numa_mem_supported = true;
>>> }
>>>
>>> static const TypeInfo sbsa_ref_info = {
>>> diff --git a/hw/core/machine.c b/hw/core/machine.c
>>> index 1689ad3..aa63231 100644
>>> --- a/hw/core/machine.c
>>> +++ b/hw/core/machine.c
>>> @@ -958,7 +958,7 @@ static void machine_initfn(Object *obj)
>>> NULL);
>>> }
>>>
>>> - if (mc->numa_mem_supported) {
>>> + if (mc->cpu_index_to_instance_props && mc->get_default_cpu_node_id) {
>>> ms->numa_state = g_new0(NumaState, 1);
>>> }
>>
>> I am wondering if @numa_mem_supported is unused here, it is unused for
>> QEMU, because the only usage of @numa_mem_supported is to initialize
>> @numa_state. Or there is other usage? So should it be removed from
>> struct MachineClass?
> You are wrong, it's not intended for numa_state initialization,
> read doc comment for it in include/hw/boards.h
> (for full story look at commit cd5ff8333a3)
>
I understand.
next prev parent reply other threads:[~2019-12-16 1:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-12 12:48 [PATCH 0/2] numa: stop abusing numa_mem_supported Igor Mammedov
2019-12-12 12:48 ` [PATCH 1/2] numa: remove not needed check Igor Mammedov
2019-12-19 17:45 ` Eduardo Habkost
2019-12-12 12:48 ` [PATCH 2/2] numa: properly check if numa is supported Igor Mammedov
2019-12-13 1:33 ` Tao Xu
2019-12-13 9:12 ` Igor Mammedov
2019-12-16 1:03 ` Tao Xu [this message]
2019-12-19 17:57 ` Eduardo Habkost
2019-12-19 13:28 ` [PATCH 0/2] numa: stop abusing numa_mem_supported Igor Mammedov
2019-12-19 13:30 ` Michael S. Tsirkin
2019-12-19 13:42 ` Igor Mammedov
2019-12-20 13:14 ` Paolo Bonzini
2019-12-20 15:11 ` Igor Mammedov
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=a0e52b4d-d6b9-3dec-35b8-a3225f07d8d5@intel.com \
--to=tao3.xu@intel.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=leif.lindholm@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=radoslaw.biernacki@linaro.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 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).