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
