Re: [Qemu-devel] Live migration sequence

[Pavel Fedin <p.fedin@samsung.com>]

 Hello!

>   b) Once you're in the device state saving (a above) you must not change guest RAM,
>      because at that point the migration code won't send any new changes across
>      to the destination. So any sync's you're going to do have to happen before/at
>      the time we stop the CPU and do the final RAM sync.  On the plus side, when
>      you're loading the device state in (a) you can be sure the RAM contents are there.

 This is good. I think, in this case i can teach the kernel (here we talk about accelerated
in-kernel irqchip implementation) to flush ITS caches when a CPU is stopped. This will do the job.

>   c) Watch out for the size of that final sync; if you have lots of these ITS
>      and they all update their 64k page at the point we stop the CPU then you're
>      going to generate a lot of RAM that needs syncing.

 Well, reducing downtime would be the next task. :) First i'd like to get it working at all.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia