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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
