All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Tao Xu <tao3.xu@intel.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>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Subject: Re: [PATCH 2/2] numa: properly check if numa is supported
Date: Fri, 13 Dec 2019 10:12:19 +0100	[thread overview]
Message-ID: <20191213101219.0aa249dc@redhat.com> (raw)
In-Reply-To: <bf9dc1f6-514a-67ac-d09b-0b515545bf22@intel.com>

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)


WARNING: multiple messages have this Message-ID (diff)
From: Igor Mammedov <imammedo@redhat.com>
To: Tao Xu <tao3.xu@intel.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: Fri, 13 Dec 2019 10:12:19 +0100	[thread overview]
Message-ID: <20191213101219.0aa249dc@redhat.com> (raw)
In-Reply-To: <bf9dc1f6-514a-67ac-d09b-0b515545bf22@intel.com>

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)



  reply	other threads:[~2019-12-13  9:12 UTC|newest]

Thread overview: 17+ 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-12 12:48   ` Igor Mammedov
2019-12-13  1:33   ` Tao Xu
2019-12-13  1:33     ` Tao Xu
2019-12-13  9:12     ` Igor Mammedov [this message]
2019-12-13  9:12       ` Igor Mammedov
2019-12-16  1:03       ` Tao Xu
2019-12-16  1:03         ` Tao Xu
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=20191213101219.0aa249dc@redhat.com \
    --to=imammedo@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=leif.lindholm@linaro.org \
    --cc=marcel.apfelbaum@gmail.com \
    --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 \
    --cc=tao3.xu@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.