From: Peter Xu <peterx@redhat.com>
To: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Cc: qemu-devel@nongnu.org,
"Alex Williamson" <alex.williamson@redhat.com>,
"Cédric Le Goater" <clg@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"David Hildenbrand" <david@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Helge Deller" <deller@gmx.de>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"John Snow" <jsnow@redhat.com>,
qemu-block@nongnu.org, "Keith Busch" <kbusch@kernel.org>,
"Klaus Jensen" <its@irrelevant.dk>,
"Jesper Devantier" <foss@defmacro.it>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Nicholas Piggin" <npiggin@gmail.com>,
qemu-ppc@nongnu.org, "John Levon" <john.levon@nutanix.com>,
"Thanos Makatos" <thanos.makatos@nutanix.com>,
"Yanan Wang" <wangyanan55@huawei.com>,
"BALATON Zoltan" <balaton@eik.bme.hu>,
"Jiaxun Yang" <jiaxun.yang@flygoat.com>,
"Daniel Henrique Barboza" <danielhb413@gmail.com>,
"David Gibson" <david@gibson.dropbear.id.au>,
"Harsh Prateek Bora" <harshpb@linux.ibm.com>,
"Alexey Kardashevskiy" <aik@ozlabs.ru>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Fabiano Rosas" <farosas@suse.de>,
"Thomas Huth" <thuth@redhat.com>,
"Laurent Vivier" <lvivier@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Aurelien Jarno" <aurelien@aurel32.net>,
"Aleksandar Rikalo" <arikalo@gmail.com>,
"Max Filippov" <jcmvbkbc@gmail.com>,
"Hervé Poussineau" <hpoussin@reactos.org>,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
"Artyom Tarasenko" <atar4qemu@gmail.com>,
"Alistair Francis" <alistair@alistair23.me>,
"Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>,
"Bin Meng" <bmeng.cn@gmail.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Anthony PERARD" <anthony@xenproject.org>,
"Paul Durrant" <paul@xen.org>,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 1/7] docs/devel: Do not unparent in instance_finalize()
Date: Thu, 18 Sep 2025 16:03:49 -0400 [thread overview]
Message-ID: <aMxlpfp_LSgiIk9Z@x1.local> (raw)
In-Reply-To: <20250917-use-v3-1-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
On Wed, Sep 17, 2025 at 07:13:26PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
>
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callback will refer to objects that are already unparented, which
> is semantically incorrect.
>
> Remove the instruction to call object_unparent(), and the exception
> of the "do not call object_unparent()" rule for instance_finalize().
>
> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
> ---
> docs/devel/memory.rst | 19 ++++++-------------
> 1 file changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/docs/devel/memory.rst b/docs/devel/memory.rst
> index 57fb2aec76e0..749f11d8a4dd 100644
> --- a/docs/devel/memory.rst
> +++ b/docs/devel/memory.rst
> @@ -161,18 +161,11 @@ or never.
> Destruction of a memory region happens automatically when the owner
> object dies.
>
> -If however the memory region is part of a dynamically allocated data
> -structure, you should call object_unparent() to destroy the memory region
> -before the data structure is freed. For an example see VFIOMSIXInfo
> -and VFIOQuirk in hw/vfio/pci.c.
Should we still keep some of these examples? After the series they'll be
doing the right things. Dynamic MRs are still slightly tricky, I think
it's still good to have some references.
> -
> You must not destroy a memory region as long as it may be in use by a
> device or CPU. In order to do this, as a general rule do not create or
> -destroy memory regions dynamically during a device's lifetime, and only
> -call object_unparent() in the memory region owner's instance_finalize
> -callback. The dynamically allocated data structure that contains the
> -memory region then should obviously be freed in the instance_finalize
> -callback as well.
> +destroy memory regions dynamically during a device's lifetime.
> +The dynamically allocated data structure that contains the
> +memory region should be freed in the instance_finalize callback.
>
> If you break this rule, the following situation can happen:
>
> @@ -198,9 +191,9 @@ this exception is rarely necessary, and therefore it is discouraged,
> but nevertheless it is used in a few places.
>
> For regions that "have no owner" (NULL is passed at creation time), the
> -machine object is actually used as the owner. Since instance_finalize is
> -never called for the machine object, you must never call object_unparent
> -on regions that have no owner, unless they are aliases or containers.
> +machine object is actually used as the owner. You must never call
> +object_unparent on regions that have no owner, unless they are aliases
> +or containers.
This looks like a completely separate change. So we start to allow
machines to be finalized now? I'm not familiar with machine object
lifecycles. Maybe split it out even if it's true?
--
Peter Xu
next prev parent reply other threads:[~2025-09-18 20:05 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-17 10:13 [PATCH v3 0/7] Do not unparent in instance_finalize() Akihiko Odaki
2025-09-17 10:13 ` [PATCH v3 1/7] docs/devel: " Akihiko Odaki
2025-09-17 16:24 ` Daniel P. Berrangé
2025-09-18 20:03 ` Peter Xu [this message]
2025-09-18 20:11 ` Peter Xu
2025-09-19 10:46 ` Akihiko Odaki
2025-09-17 10:13 ` [PATCH v3 2/7] vfio/pci: " Akihiko Odaki
2025-09-17 16:26 ` Daniel P. Berrangé
2025-09-17 10:13 ` [PATCH v3 3/7] hw/core/register: " Akihiko Odaki
2025-09-17 16:26 ` Daniel P. Berrangé
2025-09-17 10:13 ` [PATCH v3 4/7] hv-balloon: " Akihiko Odaki
2025-09-17 16:28 ` Daniel P. Berrangé
2025-09-17 10:13 ` [PATCH v3 5/7] hw/sd/sdhci: " Akihiko Odaki
2025-09-17 16:31 ` Daniel P. Berrangé
2025-09-17 10:13 ` [PATCH v3 6/7] vfio: " Akihiko Odaki
2025-09-17 16:32 ` Daniel P. Berrangé
2025-09-17 10:13 ` [PATCH v3 7/7] hw/xen: " Akihiko Odaki
2025-09-17 16:33 ` Daniel P. Berrangé
2025-09-17 11:57 ` [PATCH v3 0/7] " Daniel P. Berrangé
2025-09-17 12:24 ` Akihiko Odaki
2025-09-17 13:17 ` Daniel P. Berrangé
2025-09-17 13:23 ` Daniel P. Berrangé
2025-09-18 19:58 ` Peter Xu
2025-09-18 14:03 ` Peter Xu
2025-09-18 15:29 ` BALATON Zoltan
2025-09-18 16:20 ` Peter Xu
2025-09-18 18:23 ` Peter Xu
2025-09-19 10:49 ` Akihiko Odaki
2025-09-23 8:08 ` Paolo Bonzini
2025-09-24 4:57 ` Akihiko Odaki
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=aMxlpfp_LSgiIk9Z@x1.local \
--to=peterx@redhat.com \
--cc=aik@ozlabs.ru \
--cc=alex.bennee@linaro.org \
--cc=alex.williamson@redhat.com \
--cc=alistair@alistair23.me \
--cc=anthony@xenproject.org \
--cc=arikalo@gmail.com \
--cc=atar4qemu@gmail.com \
--cc=aurelien@aurel32.net \
--cc=balaton@eik.bme.hu \
--cc=berrange@redhat.com \
--cc=bmeng.cn@gmail.com \
--cc=clg@redhat.com \
--cc=danielhb413@gmail.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=deller@gmx.de \
--cc=edgar.iglesias@gmail.com \
--cc=eduardo@habkost.net \
--cc=farosas@suse.de \
--cc=foss@defmacro.it \
--cc=harshpb@linux.ibm.com \
--cc=hpoussin@reactos.org \
--cc=its@irrelevant.dk \
--cc=jcmvbkbc@gmail.com \
--cc=jiaxun.yang@flygoat.com \
--cc=john.levon@nutanix.com \
--cc=jsnow@redhat.com \
--cc=kbusch@kernel.org \
--cc=kraxel@redhat.com \
--cc=lvivier@redhat.com \
--cc=maciej.szmigiero@oracle.com \
--cc=marcandre.lureau@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=mst@redhat.com \
--cc=npiggin@gmail.com \
--cc=odaki@rsg.ci.i.u-tokyo.ac.jp \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=sstabellini@kernel.org \
--cc=thanos.makatos@nutanix.com \
--cc=thuth@redhat.com \
--cc=wangyanan55@huawei.com \
--cc=xen-devel@lists.xenproject.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.