Re: [Qemu-devel] Live migration sequence

[Pavel Fedin]

 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