qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH for-8.2 v3 1/6] vfio/migration: Move from STOP_COPY to STOP i


From: Cédric Le Goater
Subject: Re: [PATCH for-8.2 v3 1/6] vfio/migration: Move from STOP_COPY to STOP in vfio_save_cleanup()
Date: Fri, 11 Aug 2023 12:29:13 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 8/8/23 08:23, Avihai Horon wrote:

On 07/08/2023 18:53, Cédric Le Goater wrote:
External email: Use caution opening links or attachments


[ Adding Juan and Peter for their awareness ]

On 8/2/23 10:14, Avihai Horon wrote:
Changing the device state from STOP_COPY to STOP can take time as the
device may need to free resources and do other operations as part of the
transition. Currently, this is done in vfio_save_complete_precopy() and
therefore it is counted in the migration downtime.

To avoid this, change the device state from STOP_COPY to STOP in
vfio_save_cleanup(), which is called after migration has completed and
thus is not part of migration downtime.

What bothers me is that this looks like a device specific optimization

True, currently it helps mlx5, but this change is based on the assumption that, 
in general, VFIO devices are likely to free resources when transitioning from 
STOP_COPY to STOP.
So I think this is a good change to have in any case.


and we are loosing the error part.

I don't think we lose the error part.
AFAIU, the crucial part is transitioning to STOP_COPY and sending the final 
data.
If that's done successfully, then migration is successful.
The STOP_COPY->STOP transition is done as part of the cleanup flow, after the 
migration is completed -- i.e., failure in it does not affect the success of 
migration.
Further more, if there is an error in the STOP_COPY->STOP transition, then it's 
reported by vfio_migration_set_state().

It is indeed. I am nit-picking. Pushed on :

  https://github.com/legoater/qemu/tree/vfio-next

It can still be updated before I send a PR. I also provided custom
rpms to our QE team for extras tests.

Should follow Dynamic MSI-X allocation [1] and Joao's series regarding
vIOMMU [2] but first I will take some PTO. See you in a couple of weeks !

Cheers,

C.

[1] 
https://lore.kernel.org/qemu-devel/20230727072410.135743-1-jing2.liu@intel.com/
[2] 
https://lore.kernel.org/qemu-devel/20230622214845.3980-1-joao.m.martins@oracle.com/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]