On 14.10.25 00:50, Raphael Norwitz wrote:
On Fri, Oct 10, 2025 at 2:27 AM Vladimir Sementsov-Ogievskiy
<[email protected]> wrote:
On 10.10.25 02:43, Raphael Norwitz wrote:
On Thu, Oct 9, 2025 at 5:14 PM Vladimir Sementsov-Ogievskiy
<[email protected]> wrote:
On 09.10.25 22:09, Raphael Norwitz wrote:
A small question here but will review more thoroughly pending feedback
on my overall comments.
I really hope you didn't spent much time on these 28-31 patches :/
I spent much more time on the cleanups :)
On Wed, Aug 13, 2025 at 12:53 PM Vladimir Sementsov-Ogievskiy
<[email protected]> wrote:
[..]
--- a/migration/options.c
+++ b/migration/options.c
@@ -269,6 +269,13 @@ bool migrate_local_char_socket(void)
return s->capabilities[MIGRATION_CAPABILITY_LOCAL_CHAR_SOCKET];
}
+bool migrate_local_vhost_user_blk(void)
+{
+ MigrationState *s = migrate_get_current();
+
Where was MIGRATION_CAPABILITY_LOCAL_VHOST_USER_BLK added/defined?
It is generated by QAPI code generator.
Exactly, it's defined by 'local-vhost-user-blk' member inside
'MigrationCapability':
{ 'enum': 'MigrationCapability',
'data': ['xbzrle', 'rdma-pin-all', 'auto-converge',
...
{ 'name': 'local-vhost-user-blk', 'features': [ 'unstable' ] } ] }
and after build, the generated code is in build/qapi/qapi-types-migration.h, as
a enum:
typedef enum MigrationCapability {
MIGRATION_CAPABILITY_XBZRLE,
,,,
MIGRATION_CAPABILITY_LOCAL_VHOST_USER_BLK,
MIGRATION_CAPABILITY__MAX,
} MigrationCapability;
In v2, I'll follow the interface of virtio-net series, look at
https://patchew.org/QEMU/[email protected]/[email protected]/
so, it would be migration parameter instead of capability, like
QMP migrate-set-parameters {... backend-transfer = ["vhost-user-blk"] }
and to enable both vhost-user-blk and virtio-net-tap together:
QMP migrate-set-parameters {... backend-transfer = ["vhost-user-blk",
"virtio-net-tap"] }
Why do we need two separate migration parameters for vhost-user-blk
and virtio-net-tap? Why not have a single parameter for virtio local
migrations and, if it is set, all backends types which support local
migration can advertise and take advantage of it?
As I describe in the commit message
https://patchew.org/QEMU/[email protected]/[email protected]/
:
Why not simple boolean? To simplify migration to further versions,
when more devices will support backend-transfer migration.
Alternatively, we may add per-device option to disable backend-transfer
migration, but still:
1. It's more comfortable to set same capabilities/parameters on both
source and target QEMU, than care about each device.
2. To not break the design, that machine-type + device options +
migration capabilities and parameters are fully define the resulting
migration stream. We'll break this if add in future more
backend-transfer support in devices under same backend-transfer=true
parameter.
ACK on needing a separate migration parameter. Thanks for the references.
I would suggest having the incoming_backend field in the struct
vhost_user (or maybe even in struct vhost_dev if the tap device
migration is similar enough) rather than in struct VHostUserBlk, so
that device-specific code can be kept as similar as possible.
In v2 it will be "backend_transfer" field in struct vhost_dev.
+ return s->capabilities[MIGRATION_CAPABILITY_LOCAL_VHOST_USER_BLK];
+}
+
[..]
--
Best regards,
Vladimir
--
Best regards,
Vladimir
--
Best regards,
Vladimir
