All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
To: Claudio Fontana <cfontana@suse.de>
Cc: Laurent Vivier <lvivier@redhat.com>,
	peter.maydell@linaro.org,
	Richard Henderson <richard.henderson@linaro.org>,
	qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PULL 3/5] softmmu/cpus: Only set parallel_cpus for SMP
Date: Thu, 10 Sep 2020 12:32:18 +0200	[thread overview]
Message-ID: <c7f978df-e05a-47f5-130f-ae36e8378472@amsat.org> (raw)
In-Reply-To: <1341d50a-87e7-c497-423e-fa0e618826ee@suse.de>

On 9/10/20 10:28 AM, Claudio Fontana wrote:
> Hi Philippe,
> 
> On 9/8/20 9:56 AM, Philippe Mathieu-Daudé wrote:
>> +Laurent
>>
>> On 9/8/20 9:09 AM, Claudio Fontana wrote:
>>> On 9/7/20 6:49 PM, Philippe Mathieu-Daudé wrote:
>>>> On 9/7/20 6:30 PM, Claudio Fontana wrote:
>>>>> On 9/7/20 12:20 PM, Philippe Mathieu-Daudé wrote:
>>>>>> On 9/7/20 12:05 PM, Claudio Fontana wrote:
>>>>>>> Hi Richard,
>>>>>>>
>>>>>>> currently rebasing on top of this one,
>>>>>>> just a question, why is the patch not directly using "current_machine"?
>>>>>>
>>>>>> For user mode?
>>>>>
>>>>> In user mode I'd not expect softmmu/cpus.c to be built at all...
>>>>
>>>> Which is why :) current_machine is NULL in user-mode.
>>>
>>> Ciao Philippe,
>>>
>>> then why does the patch change softmmu/cpus.c in a way that accounts for user mode?
>>>
>>> The function that the patch changes is never called in user mode.
>>>
>>> The patch could instead use current_machine without any concern of it being NULL, it will always be set in vl.c .
>>
>> Better send a patch to prove your point :)
> 
> Yes, I am already testing without problems the cpus-refactoring series with this applied:
> 
> commit 53f6db772f1522025650441102b16be17773bdc9
> Author: Claudio Fontana <cfontana@suse.de>
> Date:   Tue Sep 8 10:59:07 2020 +0200
> 
>     accel/tcg: use current_machine as it is always set for softmmu
>     
>     current_machine is always set before accelerators are initialized,
>     so use that instead of MACHINE(qdev_get_machine()).
>     
>     Signed-off-by: Claudio Fontana <cfontana@suse.de>
> 
> diff --git a/accel/tcg/tcg-cpus.c b/accel/tcg/tcg-cpus.c
> index ec7158b55e..05af1168a2 100644
> --- a/accel/tcg/tcg-cpus.c
> +++ b/accel/tcg/tcg-cpus.c
> @@ -484,7 +484,7 @@ static void tcg_start_vcpu_thread(CPUState *cpu)
>           * then we will have cpus running in parallel.
>           */
>          if (qemu_tcg_mttcg_enabled()) {
> -            MachineState *ms = MACHINE(qdev_get_machine());
> +            MachineState *ms = current_machine;
>              if (ms->smp.max_cpus > 1) {
>                  parallel_cpus = true;
>              }
> 
> 
> 
>>
>> I have bad remember about the last time I tried to understand/modify
>> that part, because IIRC the user-mode creates some fake machine to
>> satisfy various QEMU generic code assumptions. Sincerely I now prefer
>> stay away from this; too many unmerged patches there.
> 
> 
> linux-user/main.c and bsd-user/main.c seem to use cpu_create() to create the cpus,
> then they have their own cpu_loop(), they do not use any of the cpus.c code.
> 
> By contrast, softmmu/vl.c initializes current_machine in qemu_init(),
> even before accelerator is chosen and configured.
> 
> So there is no chance currently that current_machine is not set correctly when
> the accelerator vcpu startup code in is called.

Thanks for checking and correcting me!

We are good then :)

> 
> Ciao,
> 
> CLaudio


  reply	other threads:[~2020-09-10 10:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-03 21:40 [PULL 0/5] tcg patch queue Richard Henderson
2020-09-03 21:40 ` [PULL 1/5] cputlb: Make store_helper less fragile to compiler optimizations Richard Henderson
2020-09-03 21:40 ` [PULL 2/5] tcg: Fix tcg gen for vectorized absolute value Richard Henderson
2020-09-03 21:40 ` [PULL 3/5] softmmu/cpus: Only set parallel_cpus for SMP Richard Henderson
2020-09-07 10:05   ` Claudio Fontana
2020-09-07 10:20     ` Philippe Mathieu-Daudé
2020-09-07 16:30       ` Claudio Fontana
2020-09-07 16:49         ` Philippe Mathieu-Daudé
2020-09-08  7:09           ` Claudio Fontana
2020-09-08  7:56             ` Philippe Mathieu-Daudé
2020-09-10  8:28               ` Claudio Fontana
2020-09-10 10:32                 ` Philippe Mathieu-Daudé [this message]
2020-09-03 21:41 ` [PULL 4/5] tcg: Eliminate one store for in-place 128-bit dup_mem Richard Henderson
2020-09-03 21:41 ` [PULL 5/5] tcg: Implement 256-bit dup for tcg_gen_gvec_dup_mem Richard Henderson
2020-09-06 13:07 ` [PULL 0/5] tcg patch queue Peter Maydell

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=c7f978df-e05a-47f5-130f-ae36e8378472@amsat.org \
    --to=f4bug@amsat.org \
    --cc=cfontana@suse.de \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@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 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.