On 7/22/24 23:13, Joao Martins wrote:
> By default VFIO migration is set to auto, which will support live
> migration if the migration capability is set *and* also dirty page
> tracking is supported.
>
> For testing purposes one can force enable without dirty page tracki
:
On 22/07/2024 15:53, Cédric Le Goater wrote:
On 7/19/24 19:26, Joao Martins wrote:
On 19/07/2024 15:24, Joao Martins wrote:
On 19/07/2024 15:17, Cédric Le Goater wrote:
On 7/19/24 14:05, Joao Martins wrote:
By default VFIO migration is set to auto, which will support live
migration
>-Original Message-
>From: Joao Martins
>Subject: [PATCH v6 8/9] vfio/migration: Don't block migration device dirty
>tracking is unsupported
>
>By default VFIO migration is set to auto, which will support live
>migration if the migration capability is set
By default VFIO migration is set to auto, which will support live
migration if the migration capability is set *and* also dirty page
tracking is supported.
For testing purposes one can force enable without dirty page tracking
via enable-migration=on, but that option is generally left for testing
rote:
>>>>>>>>>> On 19/07/2024 15:17, Cédric Le Goater wrote:
>>>>>>>>>>> On 7/19/24 14:05, Joao Martins wrote:
>>>>>>>>>>>> By default VFIO migration is set to auto, which will support live
>>
oao Martins wrote:
>>>>>> On 22/07/2024 15:53, Cédric Le Goater wrote:
>>>>>>> On 7/19/24 19:26, Joao Martins wrote:
>>>>>>>> On 19/07/2024 15:24, Joao Martins wrote:
>>>>>>>>> On 19/07/2024 15:17, Cédric Le Goate
:
On 7/19/24 19:26, Joao Martins wrote:
On 19/07/2024 15:24, Joao Martins wrote:
On 19/07/2024 15:17, Cédric Le Goater wrote:
On 7/19/24 14:05, Joao Martins wrote:
By default VFIO migration is set to auto, which will support live
migration if the migration capability is set *and* also dirty page
:
On 19/07/2024 15:24, Joao Martins wrote:
On 19/07/2024 15:17, Cédric Le Goater wrote:
On 7/19/24 14:05, Joao Martins wrote:
By default VFIO migration is set to auto, which will support live
migration if the migration capability is set *and* also dirty page
tracking is supported.
For testing
oao Martins wrote:
>>>>>> On 19/07/2024 15:24, Joao Martins wrote:
>>>>>>> On 19/07/2024 15:17, Cédric Le Goater wrote:
>>>>>>>> On 7/19/24 14:05, Joao Martins wrote:
>>>>>>>>> By default VFIO migration
:
On 7/19/24 14:05, Joao Martins wrote:
By default VFIO migration is set to auto, which will support live
migration if the migration capability is set *and* also dirty page
tracking is supported.
For testing purposes one can force enable without dirty page tracking
via enable-migration
dric Le Goater wrote:
>>>>>> On 7/19/24 14:05, Joao Martins wrote:
>>>>>>> By default VFIO migration is set to auto, which will support live
>>>>>>> migration if the migration capability is set *and* also dirty page
>>>>>>
On 7/22/24 17:01, Joao Martins wrote:
On 22/07/2024 15:53, Cédric Le Goater wrote:
On 7/19/24 19:26, Joao Martins wrote:
On 19/07/2024 15:24, Joao Martins wrote:
On 19/07/2024 15:17, Cédric Le Goater wrote:
On 7/19/24 14:05, Joao Martins wrote:
By default VFIO migration is set to auto
On 22/07/2024 15:53, Cédric Le Goater wrote:
> On 7/19/24 19:26, Joao Martins wrote:
>> On 19/07/2024 15:24, Joao Martins wrote:
>>> On 19/07/2024 15:17, Cédric Le Goater wrote:
>>>> On 7/19/24 14:05, Joao Martins wrote:
>>>>> By default VFIO migr
On 7/19/24 19:26, Joao Martins wrote:
On 19/07/2024 15:24, Joao Martins wrote:
On 19/07/2024 15:17, Cédric Le Goater wrote:
On 7/19/24 14:05, Joao Martins wrote:
By default VFIO migration is set to auto, which will support live
migration if the migration capability is set *and* also dirty
By default VFIO migration is set to auto, which will support live
migration if the migration capability is set *and* also dirty page
tracking is supported.
For testing purposes one can force enable without dirty page tracking
via enable-migration=on, but that option is generally left for testing
On 19/07/2024 15:24, Joao Martins wrote:
> On 19/07/2024 15:17, Cédric Le Goater wrote:
>> On 7/19/24 14:05, Joao Martins wrote:
>>> By default VFIO migration is set to auto, which will support live
>>> migration if the migration capability is set *and* also dirty pag
On 19/07/2024 15:24, Joao Martins wrote:
> On 19/07/2024 15:17, Cédric Le Goater wrote:
>> On 7/19/24 14:05, Joao Martins wrote:
>>> By default VFIO migration is set to auto, which will support live
>>> migration if the migration capability is set *and* also dirty pag
On 19/07/2024 15:17, Cédric Le Goater wrote:
> On 7/19/24 14:05, Joao Martins wrote:
>> By default VFIO migration is set to auto, which will support live
>> migration if the migration capability is set *and* also dirty page
>> tracking is supported.
>>
>> For test
On 7/19/24 14:05, Joao Martins wrote:
By default VFIO migration is set to auto, which will support live
migration if the migration capability is set *and* also dirty page
tracking is supported.
For testing purposes one can force enable without dirty page tracking
via enable-migration
By default VFIO migration is set to auto, which will support live
migration if the migration capability is set *and* also dirty page
tracking is supported.
For testing purposes one can force enable without dirty page tracking
via enable-migration=on, but that option is generally left for testing
On 18/07/2024 08:20, Duan, Zhenzhong wrote:
>
>
>> -Original Message-
>> From: Joao Martins
>> Subject: Re: [PATCH v4 11/12] vfio/migration: Don't block migration device
>> dirty tracking is unsupported
>>
>> On 17/07/2024 03:38, Duan, Zhenzhong
>-Original Message-
>From: Joao Martins
>Subject: Re: [PATCH v4 11/12] vfio/migration: Don't block migration device
>dirty tracking is unsupported
>
>On 17/07/2024 03:38, Duan, Zhenzhong wrote:
>>
>>
>>> -Original Message-
>>>
On 17/07/2024 17:02, Joao Martins wrote:
> On 17/07/2024 16:35, Joao Martins wrote:
>> On 17/07/2024 10:20, Joao Martins wrote:
>>> On 17/07/2024 03:38, Duan, Zhenzhong wrote:
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> index 34d4be2ce1b1..ce3d1b6e9a25 100644
> ---
On 17/07/2024 16:35, Joao Martins wrote:
> On 17/07/2024 10:20, Joao Martins wrote:
>> On 17/07/2024 03:38, Duan, Zhenzhong wrote:
diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
index 34d4be2ce1b1..ce3d1b6e9a25 100644
--- a/hw/vfio/migration.c
+++ b/hw/vfio/migration.c
On 17/07/2024 10:20, Joao Martins wrote:
> On 17/07/2024 03:38, Duan, Zhenzhong wrote:
>>
>>
>>> -Original Message-
>>> From: Joao Martins
>>> Subject: [PATCH v4 11/12] vfio/migration: Don't block migration device dirty
>>> tracking is u
On 7/12/24 13:47, Joao Martins wrote:
> By default VFIO migration is set to auto, which will support live
> migration if the migration capability is set *and* also dirty page
> tracking is supported.
>
> For testing purposes one can force enable without dirty page tracki
On 17/07/2024 03:38, Duan, Zhenzhong wrote:
>
>
>> -Original Message-
>> From: Joao Martins
>> Subject: [PATCH v4 11/12] vfio/migration: Don't block migration device dirty
>> tracking is unsupported
>>
>> By default VFIO migration is set to
>-Original Message-
>From: Joao Martins
>Subject: [PATCH v4 11/12] vfio/migration: Don't block migration device dirty
>tracking is unsupported
>
>By default VFIO migration is set to auto, which will support live
>migration if the migration capability is set
By default VFIO migration is set to auto, which will support live
migration if the migration capability is set *and* also dirty page
tracking is supported.
For testing purposes one can force enable without dirty page tracking
via enable-migration=on, but that option is generally left for testing
On 10/07/2024 11:38, Duan, Zhenzhong wrote:
>
>
>> -Original Message-
>> From: Joao Martins
>> Subject: [PATCH v3 09/10] vfio/migration: Don't block migration device dirty
>> tracking is unsupported
>>
>> By default VFIO migration is set to
>-Original Message-
>From: Joao Martins
>Subject: [PATCH v3 09/10] vfio/migration: Don't block migration device dirty
>tracking is unsupported
>
>By default VFIO migration is set to auto, which will support live
>migration if the migration capability is set
On 09/07/2024 08:02, Cédric Le Goater wrote:
> On 7/8/24 4:34 PM, Joao Martins wrote:
>> By default VFIO migration is set to auto, which will support live
>> migration if the migration capability is set *and* also dirty page
>> tracking is supported.
>>
>> For test
On 7/8/24 4:34 PM, Joao Martins wrote:
By default VFIO migration is set to auto, which will support live
migration if the migration capability is set *and* also dirty page
tracking is supported.
For testing purposes one can force enable without dirty page tracking
via enable-migration
By default VFIO migration is set to auto, which will support live
migration if the migration capability is set *and* also dirty page
tracking is supported.
For testing purposes one can force enable without dirty page tracking
via enable-migration=on, but that option is generally left for testing
[ ... ]
* [v4] vfio: VFIO migration support with vIOMMU
https://lore.kernel.org/qemu-devel/20230622214845.3980-1-joao.m.mart...@oracle.com/
Refreshed the patchset on upstream and pushed on vfio-9.1 branch.
/me nods Probably deserves an item on the list too related to this subject
From: "Maciej S. Szmigiero"
This way both the start and end points of migrating a particular VFIO
device are known.
Add also a vfio_save_iterate_empty_hit trace event so it is known when
there's no more data to send for that device.
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/migration.c
From: "Maciej S. Szmigiero"
Implement the multifd device state transfer via additional per-device
thread spawned from save_live_complete_precopy_begin handler.
Switch between doing the data transfer in the new handler and doing it
in the old save_state handler depending on the
From: "Maciej S. Szmigiero"
This property allows configuring at runtime whether to send the
particular device state via multifd channels when live migrating that
device.
It is ignored on the receive side and defaults to "false" for bit stream
compatibility with older QEMU versions.
From: "Maciej S. Szmigiero"
The multifd received data needs to be reassembled since device state
packets sent via different multifd channels can arrive out-of-order.
Therefore, each VFIO device state packet carries a header indicating
its position in the stream.
The last such VFIO device state
racking_init().
>
/me nods
>>> The rest is mostly VFIO internals for dirty tracking.
>>>
>> Right.
>>
>> I derailed with other work and also stuff required for iommu dirty tracking
>> that
>> I forgot about these patches, sorry.
>
> That's fine.
eds feedback on the PCI IOMMU ops. vIOMMU "iommufd" property ?
Pushed on vfio-9.1 branch.
* [RFC v2] VIRTIO-IOMMU/VFIO: Fix host iommu geometry
https://lore.kernel.org/all/20240607143905.765133-1-eric.au...@redhat.com
Pushed on vfio-9.1 branch.
Need a resend :
* [v4] vfio: V
On 06/06/2024 16:43, Cédric Le Goater wrote:
> Hello Joao,
>
> On 6/22/23 23:48, Joao Martins wrote:
>> Hey,
>>
>> This series introduces support for vIOMMU with VFIO device migration,
>> particurlarly related to how we do the dirty page tracking.
>>
>> Today vIOMMUs serve two purposes: 1) enable
Hello Joao,
On 6/22/23 23:48, Joao Martins wrote:
Hey,
This series introduces support for vIOMMU with VFIO device migration,
particurlarly related to how we do the dirty page tracking.
Today vIOMMUs serve two purposes: 1) enable interrupt remaping 2)
provide dma translation services for
From: Avihai Horon
Emit VFIO migration QAPI event when a VFIO device changes its migration
state. This can be used by management applications to get updates on the
current state of the VFIO device for their own purposes.
A new per VFIO device capability, "migration-events", is added
From: Avihai Horon
Move trace_vfio_migration_set_state() to the top of the function, add
recover_state to it, and add a new trace event to
vfio_migration_set_device_state().
This improves tracing of device state changes as state changes are now
also logged when vfio_migration_set_state() fails
Use vmstate_save_state_with_err() to improve error reporting in the
callers and store a reported error under the migration stream. Add
documentation while at it.
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Eric Auger
Reviewed-by: Avihai Horon
Signed-off-by: Cédric Le Goater
---
From: Avihai Horon
Add a new QAPI event for VFIO migration. This event will be emitted when
a VFIO device changes its migration state, for example, during migration
or when stopping/starting the guest.
This event can be used by management applications to get updates on the
current state
ver, with the newly added VFIO migration QAPI event, the
STOP_COPY event is undesirably emitted twice.
Prevent this by returning early in vfio_migration_set_state() if
new_state is the same as current device state.
Note that the STOP_COPY transition in vfio_save_complete_precopy() is
essential for VFIO devi
Add an Error** argument to vfio_migration_set_state() and adjust
callers, including vfio_save_setup(). The error will be propagated up
to qemu_savevm_state_setup() where the save_setup() handler is
executed.
Modify vfio_vmstate_change_prepare() and vfio_vmstate_change() to
store a reported error
te().
(Cedric)
* Added helper to set VFIO state and emit VFIO event. (Peter)
[1]
https://lore.kernel.org/qemu-devel/20240430051621.19597-1-avih...@nvidia.com/
[2]
https://lore.kernel.org/qemu-devel/20240509090954.16447-1-avih...@nvidia.com/
Avihai Horon (4):
qapi/vfio: Add VFIO migration QA
Add an Error** argument to vfio_migration_set_state() and adjust
callers, including vfio_save_setup(). The error will be propagated up
to qemu_savevm_state_setup() where the save_setup() handler is
executed.
Modify vfio_vmstate_change_prepare() and vfio_vmstate_change() to
store a reported error
Use vmstate_save_state_with_err() to improve error reporting in the
callers and store a reported error under the migration stream. Add
documentation while at it.
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Eric Auger
Reviewed-by: Avihai Horon
Signed-off-by: Cédric Le Goater
---
On 5/16/24 10:18, Avihai Horon wrote:
On 14/05/2024 18:31, Cédric Le Goater wrote:
External email: Use caution opening links or attachments
Add an Error** argument to vfio_migration_set_state() and adjust
callers, including vfio_save_setup(). The error will be propagated up
to
On 14/05/2024 18:31, Cédric Le Goater wrote:
External email: Use caution opening links or attachments
Use vmstate_save_state_with_err() to improve error reporting in the
callers and store a reported error under the migration stream. Add
documentation while at it.
Reviewed-by: Philippe
On 14/05/2024 18:31, Cédric Le Goater wrote:
External email: Use caution opening links or attachments
Add an Error** argument to vfio_migration_set_state() and adjust
callers, including vfio_save_setup(). The error will be propagated up
to qemu_savevm_state_setup() where the save_setup()
On 5/15/24 09:20, Eric Auger wrote:
Hi Cédric,
On 5/14/24 17:31, Cédric Le Goater wrote:
Add an Error** argument to vfio_migration_set_state() and adjust
callers, including vfio_save_setup(). The error will be propagated up
to qemu_savevm_state_setup() where the save_setup() handler is
On 5/15/24 15:21, Avihai Horon wrote:
Emit VFIO migration QAPI event when a VFIO device changes its migration
state. This can be used by management applications to get updates on the
current state of the VFIO device for their own purposes.
A new per VFIO device capability, "migration-e
On 5/15/24 15:21, Avihai Horon wrote:
Move trace_vfio_migration_set_state() to the top of the function, add
recover_state to it, and add a new trace event to
vfio_migration_set_device_state().
This improves tracing of device state changes as state changes are now
also logged when
When migrating a VFIO device that supports pre-copy, it is transitioned
to STOP_COPY twice: once in vfio_vmstate_change() and second time in
vfio_save_complete_precopy().
The second transition is harmless, as it's a STOP_COPY->STOP_COPY no-op
transition. However, with the newly added V
Emit VFIO migration QAPI event when a VFIO device changes its migration
state. This can be used by management applications to get updates on the
current state of the VFIO device for their own purposes.
A new per VFIO device capability, "migration-events", is added so events
can be en
Move trace_vfio_migration_set_state() to the top of the function, add
recover_state to it, and add a new trace event to
vfio_migration_set_device_state().
This improves tracing of device state changes as state changes are now
also logged when vfio_migration_set_state() fails (covering recover
Add a new QAPI event for VFIO migration. This event will be emitted when
a VFIO device changes its migration state, for example, during migration
or when stopping/starting the guest.
This event can be used by management applications to get updates on the
current state of the VFIO device
eter)
[1]
https://lore.kernel.org/qemu-devel/20240430051621.19597-1-avih...@nvidia.com/
[2]
https://lore.kernel.org/qemu-devel/20240509090954.16447-1-avih...@nvidia.com/
Avihai Horon (4):
qapi/vfio: Add VFIO migration QAPI event
vfio/migration: Emit VFIO migration QAPI event
vfio/migration: Don't emi
On 5/14/24 17:31, Cédric Le Goater wrote:
> Use vmstate_save_state_with_err() to improve error reporting in the
> callers and store a reported error under the migration stream. Add
> documentation while at it.
>
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Cédric Le Goater
> ---
>
Hi Cédric,
On 5/14/24 17:31, Cédric Le Goater wrote:
> Add an Error** argument to vfio_migration_set_state() and adjust
> callers, including vfio_save_setup(). The error will be propagated up
> to qemu_savevm_state_setup() where the save_setup() handler is
> executed.
>
> Modify
Add an Error** argument to vfio_migration_set_state() and adjust
callers, including vfio_save_setup(). The error will be propagated up
to qemu_savevm_state_setup() where the save_setup() handler is
executed.
Modify vfio_vmstate_change_prepare() and vfio_vmstate_change() to
store a reported error
Use vmstate_save_state_with_err() to improve error reporting in the
callers and store a reported error under the migration stream. Add
documentation while at it.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Cédric Le Goater
---
Changes in v6:
- Modified title (Avihai)
-
VFIO migration QAPI event when a VFIO device changes its
migration
state. This can be used by management applications to get updates
on the
current state of the VFIO device for their own purposes.
A new per VFIO device capability, "migration-events", is added so
events
can be en
On 5/13/24 16:34, Avihai Horon wrote:
On 13/05/2024 17:01, Cédric Le Goater wrote:
External email: Use caution opening links or attachments
On 5/9/24 11:09, Avihai Horon wrote:
Emit VFIO migration QAPI event when a VFIO device changes its migration
state. This can be used by management
in
vfio_save_complete_precopy().
The second transition is harmless, as it's a STOP_COPY->STOP_COPY no-op
transition. However, with the newly added VFIO migration QAPI event, the
STOP_COPY event is undesirably emitted twice.
Prevent this by returning early in vfio_migration_set_state() if
new_state is the s
On 13/05/2024 17:01, Cédric Le Goater wrote:
External email: Use caution opening links or attachments
On 5/9/24 11:09, Avihai Horon wrote:
Emit VFIO migration QAPI event when a VFIO device changes its migration
state. This can be used by management applications to get updates on the
current
ion. However, with the newly added VFIO migration QAPI event, the
STOP_COPY event is undesirably emitted twice.
Prevent this by returning early in vfio_migration_set_state() if
new_state is the same as current device state.
Note that the STOP_COPY transition in vfio_save_complete_precopy() is
essent
On 5/9/24 11:09, Avihai Horon wrote:
Add a new QAPI event for VFIO migration. This event will be emitted when
a VFIO device changes its migration state, for example, during migration
or when stopping/starting the guest.
This event can be used by management applications to get updates
On 5/9/24 11:09, Avihai Horon wrote:
Emit VFIO migration QAPI event when a VFIO device changes its migration
state. This can be used by management applications to get updates on the
current state of the VFIO device for their own purposes.
A new per VFIO device capability, "migration-e
Add a new QAPI event for VFIO migration. This event will be emitted when
a VFIO device changes its migration state, for example, during migration
or when stopping/starting the guest.
This event can be used by management applications to get updates on the
current state of the VFIO device
ded helper to set VFIO state and emit VFIO event. (Peter)
[1]
https://lore.kernel.org/qemu-devel/20240430051621.19597-1-avih...@nvidia.com/
Avihai Horon (3):
qapi/vfio: Add VFIO migration QAPI event
vfio/migration: Emit VFIO migration QAPI event
vfio/migration: Don't emit STOP_COPY VFIO migr
When migrating a VFIO device that supports pre-copy, it is transitioned
to STOP_COPY twice: once in vfio_vmstate_change() and second time in
vfio_save_complete_precopy().
The second transition is harmless, as it's a STOP_COPY->STOP_COPY no-op
transition. However, with the newly added V
Emit VFIO migration QAPI event when a VFIO device changes its migration
state. This can be used by management applications to get updates on the
current state of the VFIO device for their own purposes.
A new per VFIO device capability, "migration-events", is added so events
can be en
On 07/05/2024 18:51, Peter Xu wrote:
External email: Use caution opening links or attachments
On Tue, May 07, 2024 at 10:47:13AM +0300, Avihai Horon wrote:
While at it, another trivial comment is maybe it's nice to have a helper to
both update the vfio migration state, plus emitting events
On Tue, May 07, 2024 at 10:47:13AM +0300, Avihai Horon wrote:
> > While at it, another trivial comment is maybe it's nice to have a helper to
> > both update the vfio migration state, plus emitting events when necessary.
>
> I think vfio_migration_set_state() does exactly that,
or each migration state change
(since 2.4)".
This only refers to the MIGRATION event AFAIU.
Later on (in QEMU 2.6), MIGRATION_PASS event was added and the events cap was
overloaded for the first time (without changing @events description).
Now we want to add yet another use for eve
;
> >>>>>> +default:
> >>>>>> +g_assert_not_reached();
> >>>>>> +}
> >>>>>> +}
> >>>>>> +
> >>>>>> +static void vfio_migration_send_state_change_event(VFIODev
On 06/05/2024 17:39, Cédric Le Goater wrote:
External email: Use caution opening links or attachments
Hello Avihai,
On 4/30/24 07:16, Avihai Horon wrote:
When migrating a VFIO device that supports pre-copy, it is transitioned
to STOP_COPY twice: once in vfio_vmstate_change() and second
Hello Avihai,
On 4/30/24 07:16, Avihai Horon wrote:
When migrating a VFIO device that supports pre-copy, it is transitioned
to STOP_COPY twice: once in vfio_vmstate_change() and second time in
vfio_save_complete_precopy().
The second transition is harmless, as it's a STOP_COPY->STOP_COPY no-op
*vbasedev)
>>>>>> +{
>>>>>> +VFIOMigration *migration = vbasedev->migration;
>>>>>> +const char *id;
>>>>>> +Object *obj;
>>>>>> +
>>>>>> +if (!vbasedev->migration_events)
eap frog migrate_events() capability instead of
>>>> introducing its
>>>> vfio equivalent i.e.
>>>>
>>>> if (!migrate_events()) {
>>>> return;
>>>> }
>>>>
>>>> ?
>>
igration
state change (since 2.4)".
This only refers to the MIGRATION event AFAIU.
Later on (in QEMU 2.6), MIGRATION_PASS event was added and the events
cap was overloaded for the first time (without changing @events
description).
Now we want to add yet another use for events capabilit
On 01/05/2024 13:28, Avihai Horon wrote:
>
> On 01/05/2024 14:50, Joao Martins wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On 30/04/2024 06:16, Avihai Horon wrote:
>>> Emit VFIO device migration state change QAPI event when a VFIO device
>>> changes its migration
On 01/05/2024 14:50, Joao Martins wrote:
External email: Use caution opening links or attachments
On 30/04/2024 06:16, Avihai Horon wrote:
Emit VFIO device migration state change QAPI event when a VFIO device
changes its migration state. This can be used by management applications
to get
On 30/04/2024 06:16, Avihai Horon wrote:
> Emit VFIO device migration state change QAPI event when a VFIO device
> changes its migration state. This can be used by management applications
> to get updates on the current state of the VFIO device for their own
> purposes.
>
> A new per VFIO device
When migrating a VFIO device that supports pre-copy, it is transitioned
to STOP_COPY twice: once in vfio_vmstate_change() and second time in
vfio_save_complete_precopy().
The second transition is harmless, as it's a STOP_COPY->STOP_COPY no-op
transition. However, with the newly added migration
Emit VFIO device migration state change QAPI event when a VFIO device
changes its migration state. This can be used by management applications
to get updates on the current state of the VFIO device for their own
purposes.
A new per VFIO device capability, "migration-events", is added so events
From: "Maciej S. Szmigiero"
Implement the multifd device state transfer via additional per-device
thread spawned from save_live_complete_precopy_async handler.
Switch between doing the data transfer in the new handler and doing it
in the old save_state handler depending on the
From: "Maciej S. Szmigiero"
The multifd received data needs to be reassembled since device state
packets sent via different multifd channels can arrive out-of-order.
Therefore, each VFIO device state packet carries a header indicating
its position in the stream.
The last such VFIO device state
From: "Maciej S. Szmigiero"
This way both the start and end points of migrating a particular VFIO
device are known.
Add also a vfio_save_iterate_empty_hit trace event so it is known when
there's no more data to send for that device.
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/migration.c
From: Avihai Horon
VFIO migration buffer size is currently limited to 1MB. Therefore, there
is no need to check if migration rate exceeded, as in the worst case it
will exceed by only 1MB.
However, if the buffer size is later changed to a bigger value,
vfio_save_iterate() should enforce
From: Avihai Horon
Currently, vfio_save_state() returns 1 regardless of whether there is
more data to send or not. This was done to prevent a fast changing VFIO
device from potentially blocking other devices from sending their data,
as qemu_savevm_state_iterate() serialized devices.
Now that
VFIO migration buffer size is currently limited to 1MB. Therefore, there
is no need to check if migration rate exceeded, as in the worst case it
will exceed by only 1MB.
However, if the buffer size is later changed to a bigger value,
vfio_save_iterate() should enforce migration rate (similar
Currently, vfio_save_state() returns 1 regardless of whether there is
more data to send or not. This was done to prevent a fast changing VFIO
device from potentially blocking other devices from sending their data,
as qemu_savevm_state_iterate() serialized devices.
Now that
On 19/02/2024 10:12, Avihai Horon wrote:
> Hi Joao,
>
> On 12/02/2024 15:56, Joao Martins wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> By default VFIO migration is set to auto, which will support live
>> migration if the migra
1 - 100 of 912 matches
Mail list logo
