Hi Peter, On Wednesday, January 14, 2026 15:48 CET, Peter Xu <[email protected]> wrote:
> Logically, maybe we don't need to forbid migrate_incoming to only work with > a clean QEMU, because internally it's the same to snapshot load. We'll > need some special care on zero pages but I don't see a major blocker yet. > > Said that, IMHO for your use case I still wonder if the shmem idea would > still be worth exploring, or if you have explored but maybe found some high > overhead on booting QEMU every time? That's what I mentioned here: > > https://lore.kernel.org/all/[email protected]/ > > I wished that would work out already, or maybe you've tried it and it was > too slow for you. I haven’t had the chance to test it yet, but we plan to have someone evaluate and benchmark your approach against my dirty-tracking-based initial implementation. It’s good to hear there are no major blockers to supporting `migrate_incoming` on a dirty QEMU instance. If your proposed solution proves effective but restarting QEMU remains costly, we may also explore implementing the necessary changes to enable `migrate_incoming` directly on a dirty QEMU. > Your use case is indeed special, if the dirtied pages are normally not > much, the most efficient way to do this is only record the pages changed > from the snapshot and rollback only those pages, plus all device states. > > That's not a traditional "snapshot" concept, more like a "checkpoint" and > "restore", where now in migration we have CPR taking that term already.. > > https://www.qemu.org/docs/master/devel/migration/CPR.html > > But your case is slightly different from functionality, so that it will > happen completely within a single QEMU instance. > > So far, it sounds like a new QMP function v.s. snapshot save/load or > "migrate" / "migrate_incoming" to me, because it shouldn't need to record a > VM image, but VM diff (for rollback only). The bitmap you need here will > also be attached to the VM diff (again, not VM image, because a rollback > doesn't require a full image). In most of our use cases, we would have a complete snapshot anyway, and the cost is a one-time expense. However, you’re right, a diff/CoW mechanism would be sufficient. > Not sure if that's what you want, though. Anyway, IMHO anything like that > need to be justified first with above shmem idea not performing as well in > the first place. > > > > > I’m not sure if I’m still eligible for GSoC; otherwise, I would have > > applied myself :) > > I'm not sure how this will work out yet.. if there'll be a student working > on it I'll make sure anything to be posted to have you in the loop. > > Also, if it will work out, I'd expect we'll set the goal for the student to > start with the very simple, e.g. no multifd support and maybe starting with > one type of mem (anonymous?), we'll see. There might be gaps to what may > start to help in your use case too. > > Anyway, feel free to jump in anytime to share your thoughts. Sure :) Thanks for your inputs! Marco (Adding Romain in cc, as he has been leading most of our downstream QEMU modifications.)
