On Mon, Oct 20, 2025 at 01:47:12PM +0200, Markus Armbruster wrote: > Alexandr Moshkov <[email protected]> writes: > > > Thanks for review! > > > > On 10/20/25 14:55, Markus Armbruster wrote: > >> Alexandr Moshkov<[email protected]> writes: > >> > >>> In vhost_user_blk_stop() on incoming migration make force_stop = true, > >>> so GET_VRING_BASE will not be executed. > >>> > >>> Signed-off-by: Alexandr Moshkov<[email protected]> > >> Your cover letter explains why this is useful. Please work it into your > >> commit message. > > > > Ok > > > >> [...] > >> > >>> diff --git a/qapi/migration.json b/qapi/migration.json > >>> index be0f3fcc12..c9fea59515 100644 > >>> --- a/qapi/migration.json > >>> +++ b/qapi/migration.json > >>> @@ -517,9 +517,13 @@ > >>> # each RAM page. Requires a migration URI that supports seeking, > >>> # such as a file. (since 9.0) > >>> # > >>> +# @inflight-vhost-user-blk: If enabled, QEMU will migrate inflight > >>> +# region for vhost-user-blk. (since 10.2) > >>> +# > >> Any guidance why and when users would want to enable it? > >> > >> Is it a good idea to have device-specific capabilities? > > > > Hmm, maybe it's better way to make a parameter for the vhost-user-blk > > instead of migration capability? > > > > What do you think? > > I think this is a question for the migration maintainers :)
Oops, I missed this email previously.. We discussed similar things with Vladimir on virtio-net. Unless extremely necessary, we should avoid adding any cap into migration that is relevant to a specific device. Yes, per-device is better.. Thanks, -- Peter Xu
