summaryrefslogtreecommitdiff
path: root/accel
diff options
context:
space:
mode:
authorMarkus Armbruster <armbru@redhat.com>2019-03-08 14:14:34 +0100
committerMarkus Armbruster <armbru@redhat.com>2019-03-11 22:53:44 +0100
commit1a3ec8c1564f51628cce10d435a2e22559ea29fd (patch)
treebde29e423a6bdc8b5d7d7fede8f78e4ce05a1343 /accel
parentce14710f4fdfca32123d7efd3ddcbee984ef0ae5 (diff)
qdev: Fix latent bug with compat_props and onboard devices
Compatibility properties started life as a qdev property thing: we supported them only for qdev properties, and implemented them with the machinery backing command line option -global. Recent commit fa0cb34d221 put them to use (tacitly) with memory backend objects (subtypes of TYPE_MEMORY_BACKEND). To make that possible, we first moved the work of applying them from the -global machinery into TYPE_DEVICE's .instance_post_init() method device_post_init(), in commits ea9ce8934c5 and b66bbee39f6, then made it available to TYPE_MEMORY_BACKEND's .instance_post_init() method host_memory_backend_post_init() as object_apply_compat_props(), in commit 1c3994f6d2a. Note the code smell: we now have function name starting with object_ in hw/core/qdev.c. It has to be there rather than in qom/, because it calls qdev_get_machine() to find the current accelerator's and machine's compat_props. Turns out calling qdev_get_machine() there is problematic. If we qdev_create() from a machine's .instance_init() method, we call device_post_init() and thus qdev_get_machine() before main() can create "/machine" in QOM. qdev_get_machine() tries to get it with container_get(), which "helpfully" creates it as "container" object, and returns that. object_apply_compat_props() tries to paper over the problem by doing nothing when the value of qdev_get_machine() isn't a TYPE_MACHINE. But the damage is done already: when main() later attempts to create the real "/machine", it fails with "attempt to add duplicate property 'machine' to object (type 'container')", and aborts. Since no machine .instance_init() calls qdev_create() so far, the bug is latent. But since I want to do that, I get to fix the bug first. Observe that object_apply_compat_props() doesn't actually need the MachineState, only its the compat_props member of its MachineClass and AccelClass. This permits a simple fix: register MachineClass and AccelClass compat_props with the object_apply_compat_props() machinery right after these classes get selected. This is actually similar to how things worked before commits ea9ce8934c5 and b66bbee39f6, except we now register much earlier. The old code registered them only after the machine's .instance_init() ran, which would've broken compatibility properties for any devices created there. Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190308131445.17502-2-armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Diffstat (limited to 'accel')
-rw-r--r--accel/accel.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/accel/accel.c b/accel/accel.c
index 0d5b370dfd..8deb475b5d 100644
--- a/accel/accel.c
+++ b/accel/accel.c
@@ -66,6 +66,7 @@ static int accel_init_machine(AccelClass *acc, MachineState *ms)
*(acc->allowed) = false;
object_unref(OBJECT(accel));
}
+ object_set_accelerator_compat_props(acc->compat_props);
return ret;
}