All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	qemu-devel@nongnu.org, Eduardo Habkost <ehabkost@redhat.com>,
	Nikolay Igotti <igotti@gmail.com>
Subject: Re: [PATCH  v1 5/8] cpus-common: ensure auto-assigned cpu_indexes don't clash
Date: Thu, 21 May 2020 17:53:03 +0200	[thread overview]
Message-ID: <20200521175303.74faabe2@redhat.com> (raw)
In-Reply-To: <87y2pucwhi.fsf@linaro.org>

On Thu, 14 May 2020 17:27:53 +0100
Alex Bennée <alex.bennee@linaro.org> wrote:

> a
> Alex Bennée <alex.bennee@linaro.org> writes:
> 
> > Basing the cpu_index on the number of currently allocated vCPUs fails
> > when vCPUs aren't removed in a LIFO manner. This is especially true
> > when we are allocating a cpu_index for each guest thread in
> > linux-user where there is no ordering constraint on their allocation
> > and de-allocation.
> >
> > [I've dropped the assert which is there to guard against out-of-order
> > removal as this should probably be caught higher up the stack. Maybe
> > we could just ifdef CONFIG_SOFTTMU it?]

for machines where we care about cross version migration (arm/virt,s390,x86,spapr),
we do manual cpu_index assignment on keep control on its stability
So orderining probably shouldn't matter for other softmmu boards,
but what I'd watch for is arrays within devices where cpu_index is used as index
(ex: would be apic emulation (but its not affected by this patch since x86 control
cpu_index assignment))


> >
> > Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> > Cc: Nikolay Igotti <igotti@gmail.com>
> > Cc: Paolo Bonzini <pbonzini@redhat.com>
> > Cc: Igor Mammedov <imammedo@redhat.com>
> > Cc: Eduardo Habkost <ehabkost@redhat.com>
> > ---
> >  cpus-common.c | 9 ++++-----
> >  1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/cpus-common.c b/cpus-common.c
> > index 55d5df89237..5a7d2f6132b 100644
> > --- a/cpus-common.c
> > +++ b/cpus-common.c
> > @@ -61,13 +61,14 @@ static bool cpu_index_auto_assigned;
> >  static int cpu_get_free_index(void)
> >  {
> >      CPUState *some_cpu;
> > -    int cpu_index = 0;
> > +    int max_cpu_index = 0;
> >  
> >      cpu_index_auto_assigned = true;
> >      CPU_FOREACH(some_cpu) {
> > -        cpu_index++;
> > +        max_cpu_index = MAX(some_cpu->cpu_index, max_cpu_index);
> >      }
> > -    return cpu_index;
> > +    max_cpu_index++;
> > +    return max_cpu_index;
> >  }  
> 
> OK some ending up with cpu_index = 1 threw off devices that would do
> qemu_get_cpu(0) so I've tweaked the algorithm to:
> 
>   static int cpu_get_free_index(void)
>   {
>       CPUState *some_cpu;
>       int max_cpu_index = 0;
> 
>       cpu_index_auto_assigned = true;
>       CPU_FOREACH(some_cpu) {
>           if (some_cpu->cpu_index >= max_cpu_index) {
>               max_cpu_index = some_cpu->cpu_index + 1;
>           }
>       }
>       return max_cpu_index;
>   }
> 
> >  
> >  void cpu_list_add(CPUState *cpu)
> > @@ -90,8 +91,6 @@ void cpu_list_remove(CPUState *cpu)
> >          return;
> >      }
> >  
> > -    assert(!(cpu_index_auto_assigned && cpu != QTAILQ_LAST(&cpus)));
> > -
> >      QTAILQ_REMOVE_RCU(&cpus, cpu, node);
> >      cpu->cpu_index = UNASSIGNED_CPU_INDEX;
> >  }  
> 
> 



  reply	other threads:[~2020-05-21 15:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13 17:31 [PATCH v1 0/8] plugins/next (cleanup, cpu_index and lockstep) Alex Bennée
2020-05-13 17:31 ` [PATCH v1 1/8] qemu/plugin: Trivial code movement Alex Bennée
2020-05-13 17:31 ` [PATCH v1 2/8] qemu/plugin: Move !CONFIG_PLUGIN stubs altogether Alex Bennée
2020-05-13 17:31 ` [PATCH v1 3/8] qemu/qemu-plugin: Make qemu_plugin_hwaddr_is_io() hwaddr argument const Alex Bennée
2020-05-13 17:31 ` [PATCH v1 4/8] MAINTAINERS: update the orphaned cpus-common.c file Alex Bennée
2020-05-13 19:26   ` Philippe Mathieu-Daudé
2020-05-13 17:31 ` [PATCH v1 5/8] cpus-common: ensure auto-assigned cpu_indexes don't clash Alex Bennée
2020-05-14 16:27   ` Alex Bennée
2020-05-21 15:53     ` Igor Mammedov [this message]
2020-05-21 17:10       ` Alex Bennée
2020-05-22  8:46         ` Igor Mammedow
2020-05-13 17:31 ` [PATCH v1 6/8] linux-user: properly "unrealize" vCPU object Alex Bennée
2020-05-22  9:35   ` Philippe Mathieu-Daudé
2020-05-13 17:31 ` [PATCH v1 7/8] tests/tcg: add new threadcount test Alex Bennée
2020-05-15 19:51   ` Nikolay Igotti
2020-05-22  9:33   ` Philippe Mathieu-Daudé
2020-05-13 17:32 ` [PATCH v1 8/8] plugins: new lockstep plugin for debugging TCG changes Alex Bennée
2020-05-13 19:25 ` [PATCH v1 0/8] plugins/next (cleanup, cpu_index and lockstep) Philippe Mathieu-Daudé
2020-05-14  0:56 ` no-reply
2020-05-14  1:36 ` no-reply
2020-05-14  1:36 ` no-reply

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=20200521175303.74faabe2@redhat.com \
    --to=imammedo@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=ehabkost@redhat.com \
    --cc=igotti@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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.