qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: qemu-devel@nongnu.org, "Laurent Vivier" <laurent@vivier.eu>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Max Filippov" <jcmvbkbc@gmail.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Peter Xu" <peterx@redhat.com>, "Anton Johansson" <anjo@rev.ng>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	kvm@vger.kernel.org, "Marek Vasut" <marex@denx.de>,
	"David Gibson" <david@gibson.dropbear.id.au>,
	"Brian Cain" <bcain@quicinc.com>,
	"Yoshinori Sato" <ysato@users.sourceforge.jp>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	"Claudio Fontana" <cfontana@suse.de>,
	"Daniel Henrique Barboza" <dbarboza@ventanamicro.com>,
	"Artyom Tarasenko" <atar4qemu@gmail.com>,
	"Marcelo Tosatti" <mtosatti@redhat.com>,
	qemu-ppc@nongnu.org, "Liu Zhiwei" <zhiwei_liu@linux.alibaba.com>,
	"Aurelien Jarno" <aurelien@aurel32.net>,
	"Ilya Leoshkevich" <iii@linux.ibm.com>,
	"Daniel Henrique Barboza" <danielhb413@gmail.com>,
	"Bastian Koppelmann" <kbastian@mail.uni-paderborn.de>,
	"Cédric Le Goater" <clg@kaod.org>,
	"Alistair Francis" <alistair.francis@wdc.com>,
	"Alessandro Di Federico" <ale@rev.ng>,
	"Song Gao" <gaosong@loongson.cn>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Chris Wulff" <crwulff@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Alistair Francis" <alistair@alistair23.me>,
	"Fabiano Rosas" <farosas@suse.de>,
	qemu-s390x@nongnu.org, "Yanan Wang" <wangyanan55@huawei.com>,
	"Luc Michel" <luc@lmichel.fr>, "Weiwei Li" <liweiwei@iscas.ac.cn>,
	"Bin Meng" <bin.meng@windriver.com>,
	"Stafford Horne" <shorne@gmail.com>,
	"Xiaojuan Yang" <yangxiaojuan@loongson.cn>,
	"Daniel P . Berrange" <berrange@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	qemu-arm@nongnu.org, "Jiaxun Yang" <jiaxun.yang@flygoat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Aleksandar Rikalo" <aleksandar.rikalo@syrmia.com>,
	"Bernhard Beschow" <shentey@gmail.com>,
	"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
	qemu-riscv@nongnu.org, "Alex Bennée" <alex.bennee@linaro.org>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Greg Kurz" <groug@kaod.org>,
	"Michael Rolnik" <mrolnik@gmail.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>
Subject: Re: [PATCH 06/22] exec/cpu: Call cpu_remove_sync() once in cpu_common_unrealize()
Date: Wed, 22 Jan 2025 15:20:23 +0100	[thread overview]
Message-ID: <20250122152023.5ee90f50@imammedo.users.ipa.redhat.com> (raw)
In-Reply-To: <5f25576c-598f-4fd7-8238-61edcff2c411@linaro.org>

On Thu, 16 Jan 2025 19:05:46 +0100
Philippe Mathieu-Daudé <philmd@linaro.org> wrote:

> On 28/11/23 17:42, Igor Mammedov wrote:
> > On Mon, 18 Sep 2023 18:02:39 +0200
> > Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> >   
> >> While create_vcpu_thread() creates a vCPU thread, its counterpart
> >> is cpu_remove_sync(), which join and destroy the thread.
> >>
> >> create_vcpu_thread() is called in qemu_init_vcpu(), itself called
> >> in cpu_common_realizefn(). Since we don't have qemu_deinit_vcpu()
> >> helper (we probably don't need any), simply destroy the thread in
> >> cpu_common_unrealizefn().
> >>
> >> Note: only the PPC and X86 targets were calling cpu_remove_sync(),
> >> meaning all other targets were leaking the thread when the vCPU
> >> was unrealized (mostly when vCPU are hot-unplugged).
> >>
> >> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> >> ---
> >>   hw/core/cpu-common.c  | 3 +++
> >>   target/i386/cpu.c     | 1 -
> >>   target/ppc/cpu_init.c | 2 --
> >>   3 files changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/hw/core/cpu-common.c b/hw/core/cpu-common.c
> >> index a3b8de7054..e5841c59df 100644
> >> --- a/hw/core/cpu-common.c
> >> +++ b/hw/core/cpu-common.c
> >> @@ -221,6 +221,9 @@ static void cpu_common_unrealizefn(DeviceState *dev)
> >>   
> >>       /* NOTE: latest generic point before the cpu is fully unrealized */
> >>       cpu_exec_unrealizefn(cpu);
> >> +
> >> +    /* Destroy vCPU thread */
> >> +    cpu_remove_sync(cpu);
> >>   }
> >>   
> >>   static void cpu_common_initfn(Object *obj)
> >> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> >> index cb41d30aab..d79797d963 100644
> >> --- a/target/i386/cpu.c
> >> +++ b/target/i386/cpu.c
> >> @@ -7470,7 +7470,6 @@ static void x86_cpu_unrealizefn(DeviceState *dev)
> >>       X86CPUClass *xcc = X86_CPU_GET_CLASS(dev);
> >>   
> >>   #ifndef CONFIG_USER_ONLY
> >> -    cpu_remove_sync(CPU(dev));
> >>       qemu_unregister_reset(x86_cpu_machine_reset_cb, dev);
> >>   #endif  
> > 
> > missing  followup context:
> >      ...
> >      xcc->parent_unrealize(dev);
> > 
> > Before the patch, vcpu thread is stopped and onnly then
> > clean up happens.
> > 
> > After the patch we have cleanup while vcpu thread is still running.
> > 
> > Even if it doesn't explode, such ordering still seems to be wrong.  
> 
> OK.

looking at all users, some do stop vcpu thread before tearing down vcpu object
and interrupt controller, while some do it other way around or mix of both.

It's probably safe to stop vcpu thread wrt intc cleanup.
Can you check what would happen if there were a pending interrupt,
but then flowing would happen:
 1. destroying intc
 2. can vcpu thread just kicked out from KVM_RUN,
    trip over missing/invalid intc state while thread runs towards its exit point?

If above can't crash then,
I'd prefer to stop vcpu at least before vcpu cleanup is run.
i.e. put cpu_remove_sync() as the very 1st call inside of cpu_common_unrealizefn()

> >> diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
> >> index e2c06c1f32..24d4e8fa7e 100644
> >> --- a/target/ppc/cpu_init.c
> >> +++ b/target/ppc/cpu_init.c
> >> @@ -6853,8 +6853,6 @@ static void ppc_cpu_unrealize(DeviceState *dev)
> >>   
> >>       pcc->parent_unrealize(dev);
> >>   
> >> -    cpu_remove_sync(CPU(cpu));  
> > 
> > bug in current code?  
> 
> Plausibly. See:
> 
> commit f1023d21e81b7bf523ddf2ac91a48117f20ef9d7
> Author: Greg Kurz <groug@kaod.org>
> Date:   Thu Oct 15 23:18:32 2020 +0200
> 
>      spapr: Unrealize vCPUs with qdev_unrealize()
> 
>      Since we introduced CPU hot-unplug in sPAPR, we don't unrealize the
>      vCPU objects explicitly. Instead, we let QOM handle that for us
>      under object_property_del_all() when the CPU core object is
>      finalized. The only thing we do is calling cpu_remove_sync() to
>      tear the vCPU thread down.
> 
>      This happens to work but it is ugly because:
>      - we call qdev_realize() but the corresponding qdev_unrealize() is
>        buried deep in the QOM code
>      - we call cpu_remove_sync() to undo qemu_init_vcpu() called by
>        ppc_cpu_realize() in target/ppc/translate_init.c.inc
>      - the CPU init and teardown paths aren't really symmetrical
> 
>      The latter didn't bite us so far but a future patch that greatly
>      simplifies the CPU core realize path needs it to avoid a crash
>      in QOM.
> 
>      For all these reasons, have ppc_cpu_unrealize() to undo the changes
>      of ppc_cpu_realize() by calling cpu_remove_sync() at the right
>      place, and have the sPAPR CPU core code to call qdev_unrealize().
> 
>      This requires to add a missing stub because translate_init.c.inc is
>      also compiled for user mode.
> 
> >   
> >> -
> >>       destroy_ppc_opcodes(cpu);
> >>   }
> >>     
> 



  parent reply	other threads:[~2025-01-22 14:21 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-18 16:02 [PATCH 00/22] exec/cpu: Call cpu_exec_realizefn() once in cpu_common_realize() Philippe Mathieu-Daudé
2023-09-18 16:02 ` [PATCH 01/22] target/i386: Only realize existing APIC device Philippe Mathieu-Daudé
2023-09-29 20:57   ` Richard Henderson
2023-11-28 15:32   ` Igor Mammedov
2023-09-18 16:02 ` [PATCH 02/22] hw/intc/apic: Pass CPU using QOM link property Philippe Mathieu-Daudé
2023-09-29 21:01   ` Richard Henderson
2023-11-28 15:34   ` Igor Mammedov
2023-09-18 16:02 ` [PATCH 03/22] target/i386/kvm: Correct comment in kvm_cpu_realize() Philippe Mathieu-Daudé
2023-09-29 21:01   ` Richard Henderson
2023-11-28 15:50   ` Igor Mammedov
2023-09-18 16:02 ` [RFC PATCH 04/22] exec/cpu: Never call cpu_reset() before cpu_realize() Philippe Mathieu-Daudé
2023-09-29 21:03   ` Richard Henderson
2023-11-28 16:00   ` Igor Mammedov
2023-09-18 16:02 ` [PATCH 05/22] exec/cpu: Call qemu_init_vcpu() once in cpu_common_realize() Philippe Mathieu-Daudé
2023-09-29 21:04   ` Richard Henderson
2023-11-28 16:12   ` Igor Mammedov
2023-09-18 16:02 ` [PATCH 06/22] exec/cpu: Call cpu_remove_sync() once in cpu_common_unrealize() Philippe Mathieu-Daudé
2023-09-29 21:06   ` Richard Henderson
2023-11-28 16:42   ` Igor Mammedov
2025-01-16 18:05     ` Philippe Mathieu-Daudé
2025-01-16 19:02       ` Philippe Mathieu-Daudé
2025-01-22 14:20       ` Igor Mammedov [this message]
2023-09-18 16:02 ` [PATCH 07/22] exec/cpu: Introduce the CPU address space destruction function Philippe Mathieu-Daudé
2023-09-29 21:09   ` Richard Henderson
2023-10-02 11:03   ` Salil Mehta via
2023-10-02 11:03     ` Salil Mehta
2023-09-18 16:02 ` [PATCH 08/22] exec/cpu: RFC Destroy vCPU address spaces in cpu_common_unrealize() Philippe Mathieu-Daudé
2023-09-29 21:10   ` Richard Henderson
2023-09-18 16:02 ` [PATCH 09/22] target/arm: Create timers *after* accelerator vCPU is realized Philippe Mathieu-Daudé
2023-09-29 21:17   ` Richard Henderson
2023-09-18 16:02 ` [PATCH 10/22] target/hppa: Create timer " Philippe Mathieu-Daudé
2023-09-29 21:19   ` Richard Henderson
2023-09-18 16:02 ` [PATCH 11/22] target/nios2: Create IRQs " Philippe Mathieu-Daudé
2023-09-29 21:20   ` Richard Henderson
2023-09-18 16:02 ` [PATCH 12/22] target/mips: Create clock " Philippe Mathieu-Daudé
2023-09-29 21:20   ` Richard Henderson
2023-09-18 16:02 ` [PATCH 13/22] target/xtensa: Create IRQs " Philippe Mathieu-Daudé
2023-09-29 21:21   ` Richard Henderson
2023-09-18 16:02 ` [PATCH 14/22] target/sparc: Init CPU environment " Philippe Mathieu-Daudé
2023-09-29 21:21   ` Richard Henderson
2023-09-18 16:02 ` [PATCH 15/22] exec/cpu: Introduce CPUClass::verify_accel_features() Philippe Mathieu-Daudé
2023-09-29 21:22   ` Richard Henderson
2023-09-18 16:02 ` [PATCH 16/22] target/arm: Extract verify_accel_features() from cpu_realize() Philippe Mathieu-Daudé
2023-09-29 21:25   ` Richard Henderson
2023-09-18 16:02 ` [PATCH 17/22] target/i386: " Philippe Mathieu-Daudé
2023-09-18 16:02 ` [PATCH 18/22] target/s390x: Call s390_cpu_realize_sysemu from s390_realize_cpu_model Philippe Mathieu-Daudé
2023-09-18 16:34   ` David Hildenbrand
2023-09-18 16:02 ` [PATCH 19/22] target/s390x: Have s390_realize_cpu_model() return a boolean Philippe Mathieu-Daudé
2023-09-18 16:02 ` [PATCH 20/22] target/s390x: Use s390_realize_cpu_model() as verify_accel_features() Philippe Mathieu-Daudé
2023-09-18 16:02 ` [PATCH 21/22] exec/cpu: Have cpu_exec_realize() return a boolean Philippe Mathieu-Daudé
2023-09-29 21:28   ` Richard Henderson
2023-09-18 16:02 ` [PATCH 22/22] exec/cpu: Call cpu_exec_realizefn() once in cpu_common_realize() Philippe Mathieu-Daudé
2023-09-29 21:31   ` Richard Henderson

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=20250122152023.5ee90f50@imammedo.users.ipa.redhat.com \
    --to=imammedo@redhat.com \
    --cc=ale@rev.ng \
    --cc=aleksandar.rikalo@syrmia.com \
    --cc=alex.bennee@linaro.org \
    --cc=alistair.francis@wdc.com \
    --cc=alistair@alistair23.me \
    --cc=anjo@rev.ng \
    --cc=armbru@redhat.com \
    --cc=atar4qemu@gmail.com \
    --cc=aurelien@aurel32.net \
    --cc=bcain@quicinc.com \
    --cc=berrange@redhat.com \
    --cc=bin.meng@windriver.com \
    --cc=cfontana@suse.de \
    --cc=clg@kaod.org \
    --cc=crwulff@gmail.com \
    --cc=danielhb413@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=david@redhat.com \
    --cc=dbarboza@ventanamicro.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=eduardo@habkost.net \
    --cc=farosas@suse.de \
    --cc=gaosong@loongson.cn \
    --cc=groug@kaod.org \
    --cc=iii@linux.ibm.com \
    --cc=jcmvbkbc@gmail.com \
    --cc=jiaxun.yang@flygoat.com \
    --cc=kbastian@mail.uni-paderborn.de \
    --cc=kvm@vger.kernel.org \
    --cc=laurent@vivier.eu \
    --cc=liweiwei@iscas.ac.cn \
    --cc=luc@lmichel.fr \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=marex@denx.de \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=mrolnik@gmail.com \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=npiggin@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=shentey@gmail.com \
    --cc=shorne@gmail.com \
    --cc=thuth@redhat.com \
    --cc=wangyanan55@huawei.com \
    --cc=yangxiaojuan@loongson.cn \
    --cc=ysato@users.sourceforge.jp \
    --cc=zhiwei_liu@linux.alibaba.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).