hmp-commands.hx | 2 ++ qapi/qom.json | 6 ++++-- 2 files changed, 6 insertions(+), 2 deletions(-)
Creating and destroying QOM objects does not require a fully constructed
machine. Allow running object-add and object-del before machine
initialization has concluded.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
hmp-commands.hx | 2 ++
qapi/qom.json | 6 ++++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 435c591a1c..146a13c896 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1297,6 +1297,7 @@ ERST
.help = "create QOM object",
.cmd = hmp_object_add,
.command_completion = object_add_completion,
+ .flags = "p",
},
SRST
@@ -1311,6 +1312,7 @@ ERST
.help = "destroy QOM object",
.cmd = hmp_object_del,
.command_completion = object_del_completion,
+ .flags = "p",
},
SRST
diff --git a/qapi/qom.json b/qapi/qom.json
index cd0e76d564..f1e243dbe5 100644
--- a/qapi/qom.json
+++ b/qapi/qom.json
@@ -857,7 +857,8 @@
# <- { "return": {} }
#
##
-{ 'command': 'object-add', 'data': 'ObjectOptions', 'boxed': true }
+{ 'command': 'object-add', 'data': 'ObjectOptions', 'boxed': true,
+ 'allow-preconfig': true }
##
# @object-del:
@@ -877,4 +878,5 @@
# <- { "return": {} }
#
##
-{ 'command': 'object-del', 'data': {'id': 'str'} }
+{ 'command': 'object-del', 'data': {'id': 'str'},
+ 'allow-preconfig': true }
--
2.26.2
This has been committed already, but here goes anyway... Paolo Bonzini <pbonzini@redhat.com> writes: > Creating and destroying QOM objects does not require a fully constructed > machine. Allow running object-add and object-del before machine > initialization has concluded. > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Well, *some* QOM objects do require a fully constructed machine (or else device_add should be allowd in preconfig). object-add creates only *user-creatable* QOM objects (the ones implementing TYPE_USER_CREATABLE). How can we be sure the user-creatable objects we have don't require a fully constructed machine? What stops future user-creatable objects from requiring one? Would be bad, because they'd work fine in casual testing, and explode when used in the (somewhat exotic) preconfig state. In case it helps, let me list the user-creatable QOM types. QMP command {"execute": "qom-list-types", "arguments": {"implements": "qtest"}} gets us the ones compiled into a specific system emulator. My x86_64 coughs up "authz-list" "authz-list-file" "authz-pam" "authz-simple" "can-bus" "can-host-socketcan" "colo-compare" "cryptodev-backend" "cryptodev-backend-builtin" "cryptodev-vhost-user" "dbus-vmstate" "filter-buffer" "filter-dump" "filter-mirror" "filter-redirector" "filter-replay" "filter-rewriter" "input-barrier" "input-linux" "iothread" "memory-backend-file" "memory-backend-memfd" "memory-backend-ram" "pr-manager-helper" "qtest" "rng-builtin" "rng-egd" "rng-random" "secret" "secret_keyring" "sev-guest" "throttle-group" "tls-cipher-suites" "tls-creds-anon" "tls-creds-psk" "tls-creds-x509" "x-remote-object" I could do this for all system emulators, but I prefer differently boring; code inspection finds two more: "pef-guest" "s390-pv-guest"
On Tue, May 11, 2021 at 11:39:38AM -0400, Paolo Bonzini wrote: > Creating and destroying QOM objects does not require a fully constructed > machine. Allow running object-add and object-del before machine > initialization has concluded. > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- > hmp-commands.hx | 2 ++ > qapi/qom.json | 6 ++++-- > 2 files changed, 6 insertions(+), 2 deletions(-) Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
© 2016 - 2024 Red Hat, Inc.