All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Cc: Fabiano Rosas <farosas@suse.de>,
	qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	Mark Kanda <mark.kanda@oracle.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Eric Blake <eblake@redhat.com>,
	"Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>,
	Jason Wang <jasowang@redhat.com>, Ben Chaney <bchaney@akamai.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Subject: Re: [PATCH RFC 0/2] migration/vl: new -incoming config:* for early migration parameters
Date: Thu, 4 Jun 2026 09:19:13 -0400	[thread overview]
Message-ID: <aiF7UY6LPbYy7Ha_@x1.local> (raw)
In-Reply-To: <256f5918-0e33-4904-bdc9-8c0412fddd04@nutanix.com>

On Thu, Jun 04, 2026 at 11:00:17AM +0100, Mark Cave-Ayland wrote:
> On 03/06/2026 16:59, Peter Xu wrote:
> 
> > > Is this part of the same problem in that the migration object needs to be
> > > created much earlier than it is currently? And could doing this
> > > potentially remove the need for a separate CPR channel?
> > 
> > The problem is the migration object can't yet be created too early, due to
> > the fact it needs to apply compat properties.  That's why this series used
> > another approach to have a temporary early MigrationParameters object to
> > keep things until migration object is initialized (during which the temp
> > object will be destroyed).
> 
> If the MigrationParameters are needed earlier, then presumably devices can
> only depend upon the value of migration capabilities, and not the value of
> migration compat props?
> 
> In that case could you not just build the migration compat props with
> .realized_set_allowed = true in a similar way to e.g. hw/nvram/xlnx-bbram.c?

Could you elaborate?

A few contexts to provide:

Migration object (even if now a TYPE_DEVICE) doesn't use realize(), and it
will be TYPE_OBJECT soon, which is at least the current plan.  Direct use
of anything qdev specific won't work.

The other thing is, migration parameters by default should be allowed to be
set anytime after QEMU starts but before migration starts.  I don't yet
understand the reference of realized_set_allowed use case, and how that
idea can apply to migration.

Thanks,

-- 
Peter Xu



      reply	other threads:[~2026-06-04 13:19 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-28 21:29 [PATCH RFC 0/2] migration/vl: new -incoming config:* for early migration parameters Peter Xu
2026-05-28 21:29 ` [PATCH RFC 1/2] migration/vl: Allow set parameters with -incoming config:* Peter Xu
2026-05-28 22:16   ` Fabiano Rosas
2026-05-29 15:06     ` Peter Xu
2026-05-29 16:44       ` Fabiano Rosas
2026-06-01 21:32         ` Peter Xu
2026-06-02 13:37           ` Fabiano Rosas
2026-06-03 15:36             ` Mark Cave-Ayland
2026-06-03 15:55               ` Peter Xu
2026-06-04  9:21                 ` Mark Cave-Ayland
2026-06-04 15:34                   ` Peter Xu
2026-05-29  7:19   ` Vladimir Sementsov-Ogievskiy
2026-05-29 14:22     ` Peter Xu
2026-05-29  7:26   ` Vladimir Sementsov-Ogievskiy
2026-05-29 14:26     ` Peter Xu
2026-05-28 21:29 ` [PATCH RFC 2/2] migration/cpr: Opt-in "mode" parameter for early boot access Peter Xu
2026-05-28 23:24   ` Fabiano Rosas
2026-05-29 14:50     ` Peter Xu
2026-05-29 17:21       ` Fabiano Rosas
2026-05-28 22:01 ` [PATCH RFC 0/2] migration/vl: new -incoming config:* for early migration parameters Fabiano Rosas
2026-05-29 14:15   ` Peter Xu
2026-06-03  9:48     ` Daniel P. Berrangé
2026-06-03 15:50       ` Peter Xu
2026-06-03 17:15         ` Daniel P. Berrangé
2026-06-03 17:45           ` Peter Xu
2026-06-03 17:56             ` Fabiano Rosas
2026-06-03 17:51           ` Fabiano Rosas
2026-06-03 18:00             ` Daniel P. Berrangé
2026-06-03 18:46               ` Peter Xu
2026-06-03 22:00                 ` Vladimir Sementsov-Ogievskiy
2026-06-04 18:01                   ` Peter Xu
2026-06-05  7:35                     ` Vladimir Sementsov-Ogievskiy
2026-06-05 14:08                       ` Peter Xu
2026-06-05 14:37                         ` Vladimir Sementsov-Ogievskiy
2026-06-05 15:02                           ` Peter Xu
2026-06-04  8:18                 ` Daniel P. Berrangé
2026-06-04 18:08                   ` Peter Xu
2026-06-04 10:03           ` Mark Cave-Ayland
2026-06-03 15:27     ` Mark Cave-Ayland
2026-06-03 17:32       ` Fabiano Rosas
2026-06-03 15:41     ` Mark Cave-Ayland
2026-06-03 15:59       ` Peter Xu
2026-06-04 10:00         ` Mark Cave-Ayland
2026-06-04 13:19           ` Peter Xu [this message]

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=aiF7UY6LPbYy7Ha_@x1.local \
    --to=peterx@redhat.com \
    --cc=armbru@redhat.com \
    --cc=bchaney@akamai.com \
    --cc=eblake@redhat.com \
    --cc=farosas@suse.de \
    --cc=jasowang@redhat.com \
    --cc=maciej.szmigiero@oracle.com \
    --cc=mark.caveayland@nutanix.com \
    --cc=mark.kanda@oracle.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@yandex-team.ru \
    /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.