All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: "Alexandr Moshkov" <dtalexundeer@yandex-team.ru>,
	qemu-devel@nongnu.org, "Raphael Norwitz" <raphael@enfabrica.net>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Stefano Garzarella" <sgarzare@redhat.com>,
	"Kevin Wolf" <kwolf@redhat.com>,
	"Hanna Reitz" <hreitz@redhat.com>,
	"Fabiano Rosas" <farosas@suse.de>,
	"Eric Blake" <eblake@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>
Subject: Re: [PATCH v3 0/3] vhost-user-blk: support inflight migration
Date: Wed, 10 Dec 2025 10:20:59 -0500	[thread overview]
Message-ID: <aTmP28XK0X1rvJRv@x1.local> (raw)
In-Reply-To: <a8bff5ea-e1c3-4d4c-9ef7-93fa530bff0d@yandex-team.ru>

On Wed, Dec 10, 2025 at 02:41:20PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Yes, it can. And regardless of the way we chose: qdev properties or qapi,
> I don't think we need a property for backend itself. We need a property
> (or migration capability) for vhost-user-blk itself, saying that its
> backend should be migrated.

The problem is then we need to introduce the new property to all frontends
that would support the backend?  If it's a backend property, it can be one
property for the backend that all the frontends can consume.

> 
> It's a lot simpler to migrate backend inside of frontend state. If we
> migrate backend in separate, we can't control the order of backend/frontend
> stats, and will have to implement some late point in state load process,
> where both are already loaded and we can do our post-load logic.

Would MigrationPriority help when defining the VMSD?

Thanks,

-- 
Peter Xu



  reply	other threads:[~2025-12-10 15:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-10 10:39 [PATCH v3 0/3] vhost-user-blk: support inflight migration Alexandr Moshkov
2025-11-10 10:39 ` [PATCH v3 1/3] vmstate: introduce VMSTATE_VBUFFER_UINT64 Alexandr Moshkov
2025-11-10 10:39 ` [PATCH v3 2/3] vhost: add vmstate for inflight region with inner buffer Alexandr Moshkov
2025-11-10 10:39 ` [PATCH v3 3/3] vhost-user-blk: support inter-host inflight migration Alexandr Moshkov
2025-11-18 20:24 ` [PATCH v3 0/3] vhost-user-blk: support " Vladimir Sementsov-Ogievskiy
2025-11-18 22:05   ` Peter Xu
2025-12-04 19:55     ` Vladimir Sementsov-Ogievskiy
2025-12-09 16:51       ` Peter Xu
2025-12-10 11:41         ` Vladimir Sementsov-Ogievskiy
2025-12-10 15:20           ` Peter Xu [this message]
2025-12-10 15:33             ` Vladimir Sementsov-Ogievskiy

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=aTmP28XK0X1rvJRv@x1.local \
    --to=peterx@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dtalexundeer@yandex-team.ru \
    --cc=eblake@redhat.com \
    --cc=farosas@suse.de \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=raphael@enfabrica.net \
    --cc=sgarzare@redhat.com \
    --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.