vmstate: Add unmigratable flag
PATCH 1/1 vmstate: Add unmigratable flag
A first step towards getting rid of register_device_unmigratable (ivshmem and lacking vmstate support in virtio are blocking this):
Allow to register an unmigratable vmstate via qdev, i.e. tag a device declaratively.
--- hw/hw.h | 1 + savevm.c | 1 + 2 files changed, 2 insertions(+), 0 deletions(-)
hw/hw.h +1 -0
@@ -333,6 +333,7 @@ struct VMStateDescription {void (*pre_save)(void *opaque);VMStateField *fields;const VMStateSubsection *subsections; +bool unmigratable; };extern const VMStateInfo vmstate_info_bool;
savevm.c +1 -0
@@ -1234,6 +1234,7 @@ int vmstate_register_with_alias_id(DeviceState *dev, int instance_id, se->opaque = opaque; se->vmsd = vmsd; se->alias_id = alias_id; + se->no_migrate = vmsd->unmigratable;if (dev && dev->parent_bus && dev->parent_bus->info->get_dev_path) {char *id = dev->parent_bus->info->get_dev_path (dev);
Signature · 1 line
1.7.1
Quoted 5 lines · Jan Kiszka
A first step towards getting rid of
register_device_unmigratable(ivshmem and lacking vmstate support in virtio are blocking this):Allow to register an unmigratable vmstate via qdev, i.e. tag a device declaratively.
Declarative is nicer than imperative. ACK.
Quoted 5 lines · Jan Kiszka
A first step towards getting rid of
register_device_unmigratable(ivshmem and lacking vmstate support in virtio are blocking this):Allow to register an unmigratable vmstate via qdev, i.e. tag a device declaratively.
I thought part of the problem with this was that for some devices (like ivshmem), whether it can be migrated was dynamic. It depends on configuration, state, etc.
Regards,
Anthony Liguori
Quoted 31 lines
Signed-off-by Jan Kiszka<[email protected]>--- hw/hw.h | 1 + savevm.c | 1 + 2 files changed, 2 insertions(+), 0 deletions(-)hw/hw.h +1
-0@@ -333,6 +333,7 @@ struct VMStateDescription {void (*pre_save)(void *opaque);VMStateField *fields;const VMStateSubsection *subsections; +bool unmigratable; };extern const VMStateInfo vmstate_info_bool;savevm.c +1
-0@@ -1234,6 +1234,7 @@ int vmstate_register_with_alias_id(DeviceState *dev, int instance_id, se->opaque = opaque; se->vmsd = vmsd; se->alias_id = alias_id; + se->no_migrate = vmsd->unmigratable;if (dev&& dev->parent_bus&& dev->parent_bus->info->get_dev_path) {char *id = dev->parent_bus->info->get_dev_path (dev);
Quoted 10 lines · Anthony Liguori
Quoted 5 lines · Jan Kiszka
A first step towards getting rid of
register_device_unmigratable(ivshmem and lacking vmstate support in virtio are blocking this):Allow to register an unmigratable vmstate via qdev, i.e. tag a device declaratively.
I thought part of the problem with this was that for some devices (like ivshmem), whether it can be migrated was dynamic. It depends on configuration, state, etc.
That only applies to ivshmem (the other user is device assignment which is unconditionally unmigratable). And the ivshmem issue could easily be solved by defining two devices, ivshmem-peer (or just ivshmem) and ivshmem-master, eliminating the need for the role property.
I don't think there will ever be a use case for a "transformer" device that becomes unmigratable during runtime (would be a nightmare for management apps anyway).
If breaking the user interface of ivshmem for this is OK, I'll post a patch.
Jan
Quoted 17 lines · Jan Kiszka
Quoted 10 lines · Anthony Liguori
Quoted 5 lines · Jan Kiszka
A first step towards getting rid of
register_device_unmigratable(ivshmem and lacking vmstate support in virtio are blocking this):Allow to register an unmigratable vmstate via qdev, i.e. tag a device declaratively.
I thought part of the problem with this was that for some devices (like ivshmem), whether it can be migrated was dynamic. It depends on configuration, state, etc.
That only applies to ivshmem (the other user is device assignment which is unconditionally unmigratable). And the ivshmem issue could easily be solved by defining two devices, ivshmem-peer (or just ivshmem) and ivshmem-master, eliminating the need for the role property.
Quoted 9 lines
I don't think there will ever be a use case for a "transformer" device that becomes unmigratable during runtime (would be a nightmare for management apps anyway).
If breaking the user interface of ivshmem for this is OK, I'll post a patch.
Jan
The migratability of ivshmem is not dynamic in that it doesn't change at runtime, it's set when the device is created, either role=peer or role=master is specified. So iiuc, this could work with ivshmem.
Cam
Quoted 24 lines · Cam Macdonell
Quoted 23 lines · Jan Kiszka
Quoted 10 lines · Anthony Liguori
Quoted 5 lines · Jan Kiszka
A first step towards getting rid of
register_device_unmigratable(ivshmem and lacking vmstate support in virtio are blocking this):Allow to register an unmigratable vmstate via qdev, i.e. tag a device declaratively.
I thought part of the problem with this was that for some devices (like ivshmem), whether it can be migrated was dynamic. It depends on configuration, state, etc.
That only applies to ivshmem (the other user is device assignment which is unconditionally unmigratable). And the ivshmem issue could easily be solved by defining two devices, ivshmem-peer (or just ivshmem) and ivshmem-master, eliminating the need for the role property.
I don't think there will ever be a use case for a "transformer" device that becomes unmigratable during runtime (would be a nightmare for management apps anyway).
If breaking the user interface of ivshmem for this is OK, I'll post a patch.
Quoted 7 lines
Quoted 3 lines
Jan
The migratability of ivshmem is not dynamic in that it doesn't change at runtime, it's set when the device is created, either role=peer or role=master is specified. So iiuc, this could work with ivshmem.
So you are fine with breaking the interface? Everyone else as well? Then I'll cook a patch to sort at least this out for 0.15.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 29 lines · Jan Kiszka
Quoted 28 lines · Cam Macdonell
Quoted 26 lines · Jan Kiszka
Quoted 10 lines · Anthony Liguori
Quoted 5 lines · Jan Kiszka
A first step towards getting rid of
register_device_unmigratable(ivshmem and lacking vmstate support in virtio are blocking this):Allow to register an unmigratable vmstate via qdev, i.e. tag a device declaratively.
I thought part of the problem with this was that for some devices (like ivshmem), whether it can be migrated was dynamic. It depends on configuration, state, etc.
That only applies to ivshmem (the other user is device assignment which is unconditionally unmigratable). And the ivshmem issue could easily be solved by defining two devices, ivshmem-peer (or just ivshmem) and ivshmem-master, eliminating the need for the role property.
I don't think there will ever be a use case for a "transformer" device that becomes unmigratable during runtime (would be a nightmare for management apps anyway).
If breaking the user interface of ivshmem for this is OK, I'll post a patch.
Jan
Quoted 7 lines
Quoted 3 lines
The migratability of ivshmem is not dynamic in that it doesn't change at runtime, it's set when the device is created, either role=peer or role=master is specified. So iiuc, this could work with ivshmem.
So you are fine with breaking the interface? Everyone else as well? Then I'll cook a patch to sort at least this out for 0.15.
To be clear, this would break the interface in that a device cannot specify whether it's migratable via a parameter?
Quoted 7 lines
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Quoted 34 lines · Cam Macdonell
Quoted 33 lines · Jan Kiszka
Quoted 31 lines · Cam Macdonell
Quoted 17 lines · Jan Kiszka
Quoted 10 lines · Anthony Liguori
Quoted 5 lines · Jan Kiszka
A first step towards getting rid of
register_device_unmigratable(ivshmem and lacking vmstate support in virtio are blocking this):Allow to register an unmigratable vmstate via qdev, i.e. tag a device declaratively.
I thought part of the problem with this was that for some devices (like ivshmem), whether it can be migrated was dynamic. It depends on configuration, state, etc.
That only applies to ivshmem (the other user is device assignment which is unconditionally unmigratable). And the ivshmem issue could easily be solved by defining two devices, ivshmem-peer (or just ivshmem) and ivshmem-master, eliminating the need for the role property.
Quoted 9 lines
I don't think there will ever be a use case for a "transformer" device that becomes unmigratable during runtime (would be a nightmare for management apps anyway).
If breaking the user interface of ivshmem for this is OK, I'll post a patch.
Jan
The migratability of ivshmem is not dynamic in that it doesn't change at runtime, it's set when the device is created, either role=peer or role=master is specified. So iiuc, this could work with ivshmem.
Quoted 6 lines
Quoted 3 lines
So you are fine with breaking the interface? Everyone else as well? Then I'll cook a patch to sort at least this out for 0.15.
To be clear, this would break the interface in that a device cannot specify whether it's migratable via a parameter?
It will break the interface how to set up a peer or master ivshmem, from '-device ivshmem,role=X' to '-device ivshmem-X' (with the role property removed).
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux