Hi Peter, This is great to hear! I’m happy you’re taking the time to propose and mentor this. I’m definitely interested in seeing what comes out of it, thanks for putting me in the loop.
Regarding your proposed Fast Snapshot Load, it’s certainly more widely applicable and doesn’t require new QMP commands or extensive configurations (beyond mapped-ram), compared to what I had in mind. I think it will be beneficial for our use case regardless. I’d still be interested in trying to improve it further using dirty tracking at some point, to ignore pages that haven’t been written between two loadvm of the same snapshot. This would probably apply only to legacy snapshot though, as file migration expects a clean QEMU process. I’m not sure if I’m still eligible for GSoC; otherwise, I would have applied myself :) Best, Marco (removing people from CC to reduce noise) On Tuesday, January 13, 2026 16:29 CET, Peter Xu <[email protected]> wrote: > On Mon, Jan 05, 2026 at 04:47:22PM -0500, Stefan Hajnoczi wrote: > > Dear QEMU and KVM communities, > > QEMU will apply for the Google Summer of Code internship > > program again this year. Regular contributors can submit project > > ideas that they'd like to mentor by replying to this email by > > January 30th. > > There's one idea from migration side that should be self-contained, please > evaluate if this suites for the application. > > I copied Marco who might be interested on such project too at least from an > user perspective on fuzzing [1]. > > [1] https://lore.kernel.org/all/193e5a-681dfa80-3af-701c0f80@227192887/ > > Thanks, > > === Fast Snapshot Load === > > '''Summary:''' Fast loadvm process based on postcopy approach > > We have two common ways to load snapshots: (1) QMP "snapshot-load", or QMP > "migrate_incoming" with a "file:" URI. The idea to be discussed here should > apply to either form of loadvm, however here we will focus on "file:" > migration only, because it should be the modern and suggested way of using > snapshots nowadays. > > Load snapshot currently requires all VM data (RAM states and the rest > device states) to be loaded into the QEMU instance before VM starts. > > It is not required, though, to load guest memory to start the VM. For > example, in a postcopy live migration process, QEMU uses userfaultfd to > allow VM run without all of the guest memory migrated. A similar technique > can also be used in a loadvm process to make loadvm very fast, starting the > VM almost immediately right after the loadvm command. > > The idea is simple: we can start the VM right after loading device states > (but without loading the guest memory), then QEMU can start the VM. In the > background, the loadvm process should keep loading all the VM data in an > atomically way. Meanwhile, the vCPUs may from time to time access a missing > guest page. QEMU needs to trap these accesses with userfaultfd, and resolve > the page faults. > > After loading all the RAM state, the whole loadvm procedure is completed. > > This feature needs to depend on mapped-ram feature, which allows offsetting > into the snapshots to find whatever page being asked by the guest vCPUs at > any point in time. > > This feature may not be very help in VM suspend / resume use cases, because > in those cases the VM was down previously, normally it's fine waiting for > the VM to be fully loaded. However, it might be useful in some other cases > (like, frequently loading snapshots). > > '''Links:''' > * https://wiki.qemu.org/ToDo/LiveMigration#Fast_load_snapshot > > '''Details:''' > * Skill level: advanced > * Language: C > * Mentor: Peter Xu <[email protected]>, peterx (on #qemu IRC) > > -- > Peter Xu >
