From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B5F80CD98CF for ; Wed, 10 Jun 2026 18:31:58 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1wXNhp-0008H6-S8; Wed, 10 Jun 2026 14:31:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wXNhn-000888-3z for qemu-rust@nongnu.org; Wed, 10 Jun 2026 14:31:11 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wXNhk-0000MF-9n for qemu-rust@nongnu.org; Wed, 10 Jun 2026 14:31:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1781116264; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=08yRJLGeOutE7WIQdWEGFM7bIAmFYFUntuqs8+y11oM=; b=PYSA9pG4FRtCZKrNLio/2wy1QezPo3jOFM+mDNqzZv+Y7jjvoJfPJY8M8YqhZPx/T1V7AG iVVr2taMpKpf13+wKWs/BQAx68W7jgQ+qkmW56BQp9ohMeC/SOA1F1PWKEF0ovARhy8evY iht9aAV62l1TbcJm+/u2gToeC2Qlbxc= Received: from mail-ot1-f72.google.com (mail-ot1-f72.google.com [209.85.210.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-36-tZNq3go8OJW_2BGhIl9VeA-1; Wed, 10 Jun 2026 14:31:02 -0400 X-MC-Unique: tZNq3go8OJW_2BGhIl9VeA-1 X-Mimecast-MFC-AGG-ID: tZNq3go8OJW_2BGhIl9VeA_1781116262 Received: by mail-ot1-f72.google.com with SMTP id 46e09a7af769-7e6eeff3b75so3936331a34.0 for ; Wed, 10 Jun 2026 11:31:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781116262; x=1781721062; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=08yRJLGeOutE7WIQdWEGFM7bIAmFYFUntuqs8+y11oM=; b=bnsUNne0LAEJRQwu1+d/pd+kyRVS1H5Re1NNIBiNdjmlv6ZvEt+obxhnfnQR2XvjlN gKPfLm2AQPG1wyebBAFhPvjxOfWlPYBsq7Ri2kREAD8Zm5OZh74yWliRJFkf0JFqsJgD zf7vB+tgGt/DOwH38SeY6EXldVtol1l2n9zYPuqZw2ctc4YXmyRPO8lPLAGz5ZwlYk+Q J+5cox03EC42Ao/Jr/H3Hfx9xNhH53fZd6Mjo1O/HrDB31filgwiwyrlKJqRaoIS8BO5 t6ppQ4KBVhU/O6yRDAwptZ/5oADqxMxVS8S039AR08KIacT7LK7qb1lRV8vXoCawVH0z fB3A== X-Forwarded-Encrypted: i=1; AFNElJ/u8Yj7NB/tOSnV06kXH4jprFv5Qixc+FVLCCVlb9Vn3N3lEnnaP3HIb7HQR36knPSTN+vC7y5/jzU=@nongnu.org X-Gm-Message-State: AOJu0Yz1BByLAXkRYppxL3ZTxbkT2nelCEUBQ9+rh04TsFilReTgNuwV 35GDnnKPGxDEKp/I8GrfJXImzl13UOB/R1nw4Ag2doj4/LVOpaElvJAp+BuhiBwlUHJXECCfdpf 1c2QgUfb/6XvX8uVN7L+CaL53nuMzFIiRpHcgR7BVxEfXVVrmN8PCWXg= X-Gm-Gg: Acq92OGCM9pAl6e+iMQ4ns7f0JW4u/1XSW4vxbADyxE7J88Z+l4WOwwa0uO9tgkoJHi J9Bxs0QzxUNZptgHYLBeKrcgx63+TBe7lxN5apYEjDA0UPRASYbPO5FZbPowEx5cugodLedE9Xv qpeZC8j4k2TwnfsLYtPpO9qqLbMaqD+DB3yskEKef2x8HJJHFb5ONw0Ps3xHkN2NktIleGA4e7v 2nPfkWZXHt6v0sGwfQCCGgkXxj6TtE2A9uHAu5oFcgAtcBReCNDm7jPrvh2KCVvJG6+gsGVLgmW gzc8r2CNSseuG5EvLl1HJOU3EutFpeLivCMT1kc1OvFPJl6ewOlqitzV8FYkXM01iJTI+EWvJVw gukt0Lw1cZJxryxohM6QEiM71VA== X-Received: by 2002:a05:6830:4424:b0:7dc:dd19:7f69 with SMTP id 46e09a7af769-7e7707be2femr131741a34.17.1781116261612; Wed, 10 Jun 2026 11:31:01 -0700 (PDT) X-Received: by 2002:a05:6830:4424:b0:7dc:dd19:7f69 with SMTP id 46e09a7af769-7e7707be2femr131704a34.17.1781116261015; Wed, 10 Jun 2026 11:31:01 -0700 (PDT) Received: from x1.local ([142.189.10.167]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e6e78de8bdsm16737947a34.16.2026.06.10.11.30.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2026 11:31:00 -0700 (PDT) Date: Wed, 10 Jun 2026 14:30:57 -0400 From: Peter Xu To: Fabiano Rosas Cc: qemu-devel@nongnu.org, qemu-arm@nongnu.org, =?utf-8?Q?C=C3=A9dric?= Le Goater , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Daniel P =?utf-8?B?LiBCZXJyYW5nw6k=?= , Vladimir Sementsov-Ogievskiy , Peter Maydell , "Dr . David Alan Gilbert" , Eric Blake , Akihiko Odaki , Paolo Bonzini , Kevin Wolf , Sana Sharma , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Juraj Marcin , qemu-rust@nongnu.org, Markus Armbruster , Mark Cave-Ayland Subject: Re: [PATCH v2 00/10] migration/qom: Remove TYPE_DEVICE dependency on migration object Message-ID: References: <20260609172514.2037645-1-peterx@redhat.com> <87jys75npb.fsf@suse.de> MIME-Version: 1.0 In-Reply-To: <87jys75npb.fsf@suse.de> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: bI8abI-mqBsT4DKhhgE9pupx8HkkwKne2pyMRUa9kkg_1781116262 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Received-SPF: pass client-ip=170.10.133.124; envelope-from=peterx@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -24 X-Spam_score: -2.5 X-Spam_bar: -- X-Spam_report: (-2.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.445, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-rust@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: QEMU Rust-related patches and discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-rust-bounces+qemu-rust=archiver.kernel.org@nongnu.org Sender: qemu-rust-bounces+qemu-rust=archiver.kernel.org@nongnu.org On Tue, Jun 09, 2026 at 07:54:56PM -0300, Fabiano Rosas wrote: > Hi, > > After we discussed your v1 I started playing with this in parallel and > stumbled into pretty much all of the issues this series resolves. Nice > work! Good to know at least it looks reasonable for someone.. thanks. :) Looks like Dan still has concern that I use the ptrs in obj props but I'll discuss it later separately. > > I applied a patch [0] on top of this series to allow using the > command-line to create the migration object. It can set all (most) > options with -object migration,id=mig1,key=val,... > > $ ~/qemu-system-x86_64 -nodefaults -nographic -S \ > -object migration,id=mig1,announce-initial=99,downtime-limit=99,multifd-channels=99,multifd-compression=zlib,multifd=on > ... > (qemu) info migrate_parameters > (qemu) info migrate_capabilities > ... > announce-initial: 99 ms > downtime-limit: 99 ms > multifd-channels: 99 > multifd-compression: zlib > multifd: on > > I'm not saying we should do that now. I just want to check with you to > make sure we're not closing the door for future improvements: IIUC it works, maybe indeed it's a better way than "-incoming config:" at least in that we stick with the current APIs. Said that, it does bypass the singleton work I did previously: https://lore.kernel.org/r/20241029211607.2114845-1-peterx@redhat.com Which was also unfortunately got rejected.. So, I suppose this is still fine that all the tricks resides in migration/ so far, maybe this is acceptable. But then, we'll need to make sure the rest QEMU object code doesn't have assumption that all objects can be created more than one.. and making sure nothing crash elsewhere: when it crashes or works inproperly, we may face again that singleton problem one way or another. That's so far the only concern I have. > > 1) It seems the "help" option is tied to the class. Setting options > work, but the help says otherwise: > > $ ~/qemu-system-x86_64 -nographic -object migration,id=mig1,help > There are no options for migration. This one is easy, something like this should work: bool type_print_class_properties(const char *type) { + g_autoptr(Object) obj = NULL; ObjectClass *klass; ObjectPropertyIterator iter; ObjectProperty *prop; @@ -134,7 +135,12 @@ bool type_print_class_properties(const char *type) } array = g_ptr_array_new(); - object_class_property_iter_init(&iter, klass); + if (object_class_is_abstract(klass)) { + object_class_property_iter_init(&iter, klass); + } else { + obj = object_new_with_class(klass); + object_property_iter_init(&iter, obj); + } while ((prop = object_property_iter_next(&iter))) { if (!prop->set) { continue; > > 2) user_creatable_add_qapi > > The command line parsing goes through user_creatable_add_qapi() and > instantiates an object. Since migrate_params_init runs from inside > .instance_init, it cannot see any parameters that are set this way. > > Moreover, the migration_object_init() call from vl.c will init a > second migration object. > > In the patch below I have hacked the current_migration assignment to > first check if the object has already been created and use that > instead of creating a new one. Yeah that trick should work at least for now, except the concern I raised above. Since the tap work is unblocked (by temporarily introducing the tap flag), I plan to put aside the "-incoming config:*" work a bit. We'll need to pick it up at least when there's yet another similiar use case like tap or "mode" of CPR, but then lower priority. But let me know if you or anyone still think we should have it land earlier, I can re-prioritize that. > > How does this work for normal objects? I suppose most of them have the > TYPE_DEVICE as a parent, so they're not hanging in the "objects" > container. I may not get the real question behind, but.. iiuc normal objects shouldn't be sub-class of TYPE_DEVICE, and they should work fine with -object *help, and they should be able to be created with multiple instances in most cases. > > 3) TLS (of course) > > With the patch below, setting TLS options from the cmdline asserts: > visit_start_alternate: Assertion `!(v->type & VISITOR_INPUT)' failed. > (just mentioning in case it can affect the design of this series) Oh, I didn't really notice we'll have issue with it.. I did the string prop solution for tls* by pure accident, because we already assumed it's always strings anyway and it's trivial to use the object prop str helpers. I didn't expect it an issue when used with string inputs. So I assume for those we need to rely on JSON formats? -object '{"qom-type": "migration", "id": "mig1", "tls-creds": "SOMETHING"}' > > [0] > -->8-- > From 8c6c0743f1659d9df45e80334e8dc5f068ff984e Mon Sep 17 00:00:00 2001 > From: Fabiano Rosas > Date: Tue, 9 Jun 2026 16:00:21 -0300 > Subject: [PATCH] wip > > --- > migration/migration.c | 11 ++++++++++- > migration/options.c | 1 + > qapi/qom.json | 29 +++++++++++++++++++++++++++++ > 3 files changed, 40 insertions(+), 1 deletion(-) > > diff --git a/migration/migration.c b/migration/migration.c > index ae0c373549..22c8ced766 100644 > --- a/migration/migration.c > +++ b/migration/migration.c > @@ -297,7 +297,16 @@ void migration_object_init(void) > { > /* This can only be called once. */ > assert(!current_migration); > - current_migration = MIGRATION(object_new(TYPE_MIGRATION)); > + > + Object *root = object_get_objects_root(); > + ObjectProperty *prop = g_hash_table_lookup(root->properties, "mig1"); > + > + if (prop->opaque) { > + current_migration = prop->opaque; > + object_ref(current_migration); > + } else { > + current_migration = MIGRATION(object_new(TYPE_MIGRATION)); > + } A quick comment for this one; maybe better with: Object *mig_obj = object_resolve_path_component(object_get_objects_root(), "mig1"); Or even better: static int find_migration_object(Object *obj, void *opaque) { if (object_dynamic_cast(obj, TYPE_MIGRATION)) { *(Object **)opaque = obj; return 1; } return 0; } Then: object_child_foreach(object_get_objects_root(), find_migration_object, &existing); > > /* > * Init the migrate incoming object as well no matter whether > diff --git a/migration/options.c b/migration/options.c > index 1cc99382d3..88f02c45a1 100644 > --- a/migration/options.c > +++ b/migration/options.c > @@ -21,6 +21,7 @@ > #include "qapi/qapi-visit-migration.h" > #include "qapi/qmp/qerror.h" > #include "qobject/qnull.h" > +#include "qom/object_interfaces.h" > #include "system/runstate.h" > #include "migration/colo.h" > #include "migration/cpr.h" > diff --git a/qapi/qom.json b/qapi/qom.json > index dd45ac1087..fe7dd4673c 100644 > --- a/qapi/qom.json > +++ b/qapi/qom.json > @@ -8,6 +8,11 @@ > { 'include': 'block-core.json' } > { 'include': 'common.json' } > { 'include': 'crypto.json' } > +# FIXME: this requires --disable-tools due to: > +# /usr/bin/ld.bfd: libqemuutil.a.p/meson-generated_.._qapi_qapi-commands-migration.c.o: > +# in function `qmp_marshal_query_migr: qemu/build/qapi/qapi-commands-migration.c:48:(.text+0x181c): > +# undefined reference to `qmp_query_migrate' > +{ 'include': 'migration.json' } > > ## > # *********************** > @@ -1187,6 +1192,28 @@ > 'data': { '*cpu-affinity': ['uint16'], > '*node-affinity': ['uint16'] } } > > + > +## > +# @MigProperties: > +# > +# Properties for migration objects. > +# > +# @multifd: this is a capability and therefore is not part of > +# MigrationParameters yet (WIP). (default: 0) > +# > +# @store-global-state: this is a compat property and therefore is not > +# part of MigrationParameters. It's probably best to keep it like > +# this so we don't have to deal with previously impossible > +# scenarios if the user tries to set it via set-migrate (default: > +# 0) > +# > +# Since: 11.1 > +## > +{ 'struct': 'MigProperties', > + 'base': 'MigrationParameters', > + 'data': { '*multifd': 'bool', > + '*store-global-state': 'bool' } } > + > ## > # @ObjectType: > # > @@ -1237,6 +1264,7 @@ > 'memory-backend-ram', > { 'name': 'memory-backend-shm', > 'if': 'CONFIG_POSIX' }, > + 'migration', > 'pef-guest', > { 'name': 'pr-manager-helper', > 'if': 'CONFIG_LINUX' }, > @@ -1315,6 +1343,7 @@ > 'memory-backend-ram': 'MemoryBackendProperties', > 'memory-backend-shm': { 'type': 'MemoryBackendShmProperties', > 'if': 'CONFIG_POSIX' }, > + 'migration': 'MigProperties', > 'pr-manager-helper': { 'type': 'PrManagerHelperProperties', > 'if': 'CONFIG_LINUX' }, > 'qtest': 'QtestProperties', > -- > 2.53.0 > > -- Peter Xu