qemu-devel.nongnu.org archive mirror
 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>
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:13 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 [this message]
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=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 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).