qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: qemu-devel@nongnu.org
Cc: peterx@redhat.com, "Fabiano Rosas" <farosas@suse.de>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Juraj Marcin" <jmarcin@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	"Dr . David Alan Gilbert" <dave@treblig.org>,
	"Cédric Le Goater" <clg@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>
Subject: [PATCH 0/4] QOM: Singleton interface
Date: Thu, 24 Oct 2024 12:56:23 -0400	[thread overview]
Message-ID: <20241024165627.1372621-1-peterx@redhat.com> (raw)

This patchset introduces the singleton interface for QOM.

The singleton interface is as simple as "this class can only create one
instance".

We used to have similar demand when working on all kinds of vIOMMUs,
because in most cases that I am aware of, vIOMMU must be a singleton as
it's closely bound to the machine and also the root PCIe systems.  We used
to have a bunch of special code guarding those, for example, X86 has
pc_machine_device_pre_plug_cb() just to detect when vIOMMU is created more
than once.

There is a similar demand raising recently (even if the problem existed
over years) when we were looking at a migration bug, that part of it was
involved with the current_migration global pointer being referenced
anywhere, even after the migration object was finalize()ed.  So far without
singleton support, there's no way to reset the variable properly.
Declaring migration object to be a singleton also just makes sense, e.g.,
dynamically creating migration objects on the fly with QMP commands doesn't
sound right..

The idea behind is pretty simple: any object that can only be created once
can now declare the TYPE_SINGLETON interface, then QOM facilities will make
sure it won't be created more than once.  For example, qom-list-properties,
device-list-properties, etc., will be smart enough to not try to create
temporary singleton objects now.  Meanwhile, we also guard device-add paths
so that it'll fail properly if it's created more than once (and iff it's a
TYPE_DEVICE first).

The 1st patch introduces the QOM interface, while I made both x86-iommu and
migration as the initial users of it, so it's really more about the 1st
patch to discuss first.  I didn't yet touch ARM/SMMU as it's also more
complicated; I also didn't yet dig anything else that may apply, but I do
feel like this can apply more than the two attached here.  Hopefully the
two use cases can be good enough to start the discussion.

Thanks,

Peter Xu (4):
  qom: TYPE_SINGLETON interface
  x86/iommu: Make x86-iommu a singleton object
  migration: Make migration object a singleton object
  migration: Reset current_migration properly

 include/qom/object_interfaces.h | 47 +++++++++++++++++++++++++++++++++
 hw/i386/x86-iommu.c             | 14 ++++++++++
 migration/migration.c           | 36 ++++++++++++++++++++++---
 qom/object.c                    |  3 +++
 qom/object_interfaces.c         | 24 +++++++++++++++++
 qom/qom-qmp-cmds.c              | 22 ++++++++++++---
 system/qdev-monitor.c           |  7 +++++
 7 files changed, 147 insertions(+), 6 deletions(-)

-- 
2.45.0



             reply	other threads:[~2024-10-24 16:57 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-24 16:56 Peter Xu [this message]
2024-10-24 16:56 ` [PATCH 1/4] qom: TYPE_SINGLETON interface Peter Xu
2024-10-24 20:02   ` Philippe Mathieu-Daudé
2024-10-24 20:53     ` Peter Xu
2024-10-25 15:11       ` Philippe Mathieu-Daudé
2024-10-25 16:21         ` Peter Xu
2024-10-25  8:07   ` Markus Armbruster
2024-10-25 15:17     ` Peter Xu
2024-10-25  9:51   ` Daniel P. Berrangé
2024-10-25 16:17     ` Peter Xu
2024-10-25 16:22       ` Daniel P. Berrangé
2024-10-25 22:10         ` Peter Xu
2024-10-29  0:01           ` Peter Xu
2024-10-25 16:37     ` Peter Xu
2024-10-24 16:56 ` [PATCH 2/4] x86/iommu: Make x86-iommu a singleton object Peter Xu
2024-10-25  9:25   ` Markus Armbruster
2024-10-25 21:55     ` Peter Xu
2024-10-25 22:13       ` Peter Xu
2024-11-07 11:12         ` Markus Armbruster
2024-11-07 15:29           ` Peter Xu
2024-11-08  8:50             ` Markus Armbruster
2024-10-29 10:47   ` Daniel P. Berrangé
2024-10-29 14:32     ` Peter Xu
2024-10-24 16:56 ` [PATCH 3/4] migration: Make migration object " Peter Xu
2024-10-24 19:20   ` Fabiano Rosas
2024-10-24 16:56 ` [PATCH 4/4] migration: Reset current_migration properly Peter Xu
2024-10-24 19:34   ` Fabiano Rosas
2024-10-24 20:15     ` Peter Xu
2024-10-24 20:51       ` Fabiano Rosas
2024-10-25  7:38 ` [PATCH 0/4] QOM: Singleton interface Markus Armbruster
2024-10-25 15:01   ` Peter Xu
2024-10-29 10:42     ` Daniel P. Berrangé
2024-10-29 14:45       ` Peter Xu
2024-10-29 16:04         ` Daniel P. Berrangé
2024-10-29 17:05           ` Peter Xu
2024-10-29 17:17             ` Daniel P. Berrangé
2024-12-11  8:19             ` Markus Armbruster
2024-12-11 22:10               ` Peter Xu

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=20241024165627.1372621-1-peterx@redhat.com \
    --to=peterx@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=clg@redhat.com \
    --cc=dave@treblig.org \
    --cc=eduardo@habkost.net \
    --cc=farosas@suse.de \
    --cc=imammedo@redhat.com \
    --cc=jmarcin@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.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 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).