This series refactors postcopy and mapped-ram code to make the
userfaultfd infrastructure reusable beyond postcopy live migration.
The goal is to prepare for fast snapshot load, which will use
userfaultfd to load guest RAM pages on demand from a snapshot file
instead of reading all pages before starting the VM.

All three patches are pure refactoring with no functional change.

Patch 1 introduces a callback for the fault thread's page request
handler, so the page supply mechanism can be swapped (network for
postcopy, local file for snapshot load).

Patch 2 extracts generic uffd setup (open, register, fault thread,
temp pages) from postcopy_ram_incoming_setup() into a shared
uffd_setup_incoming() function.

Patch 3 splits parse_ramblock_mapped_ram() so that the header and
bitmap can be read without immediately loading all page data. This
allows a future caller to read only the metadata and defer page
loading to a fault handler.

Tested with mapped-ram precopy file migration tests. Postcopy tests
require userfaultfd, which was not available in my test environment,
but no postcopy logic was changed.

This work is part of my preparation for the GSoC 2026 "Fast Snapshot
Load" project.

Signed-off-by: Takeru Hayasaka <hayatake396@gmail.com>
---
Takeru Hayasaka (3):
      migration/postcopy: Extract page fault handler callback
      migration/postcopy: Factor out uffd_setup_incoming() from postcopy setup
      migration/ram: Split mapped-ram header and page loading

 migration/migration.h    |  5 +++
 migration/postcopy-ram.c | 86 +++++++++++++++++++++++++++++++++++-------------
 migration/postcopy-ram.h | 27 +++++++++++++++
 migration/ram.c          | 52 +++++++++++++++++++++++++----
 4 files changed, 142 insertions(+), 28 deletions(-)
---
base-commit: 8e711856d7639cbffa51405f2cc2366e3d9e3a23
change-id: 20260327-fast-snapshot-refactor-3c6bb472b777

Best regards,
--  
Takeru Hayasaka <hayatake396@gmail.com>

Hi, Takeru,

On Mon, Mar 30, 2026 at 07:04:40PM +0000, Takeru Hayasaka wrote:
> This series refactors postcopy and mapped-ram code to make the
> userfaultfd infrastructure reusable beyond postcopy live migration.
> The goal is to prepare for fast snapshot load, which will use
> userfaultfd to load guest RAM pages on demand from a snapshot file
> instead of reading all pages before starting the VM.
> 
> All three patches are pure refactoring with no functional change.
> 
> Patch 1 introduces a callback for the fault thread's page request
> handler, so the page supply mechanism can be swapped (network for
> postcopy, local file for snapshot load).
> 
> Patch 2 extracts generic uffd setup (open, register, fault thread,
> temp pages) from postcopy_ram_incoming_setup() into a shared
> uffd_setup_incoming() function.
> 
> Patch 3 splits parse_ramblock_mapped_ram() so that the header and
> bitmap can be read without immediately loading all page data. This
> allows a future caller to read only the metadata and defer page
> loading to a fault handler.

Thanks for your interest and enthusiasm to the QEMU community.  Said that,
please hold off a bit on sending patches that enable fast snapshot load for
now, even for preparations.

The problem is, this topic, as announced, is to be developed by a GSoC
student only later. We want to make sure this topic will be done during the
GSoC period by the selected candidate, and we will also need to evalute the
progress no matter who is doing it.

I'm not sure if it's fair if any of the applicants start sending patches.
I also don't hope to see multiple versions of impl floating around.  IMHO
it's slightly against how collaboration works upstream when we know there
can be work collisions and we should avoid it from happening.

Feel free to send whatever patches that do not have direct involvement with
this specific topic.

> 
> Tested with mapped-ram precopy file migration tests. Postcopy tests
> require userfaultfd, which was not available in my test environment,
> but no postcopy logic was changed.

When postcopy code is changed, I think it needs to be tested.

Could you explain what do you mean by "userfaultfd, which was not available
in my test environment"?  Are you using Linux?

Thanks,

> 
> This work is part of my preparation for the GSoC 2026 "Fast Snapshot
> Load" project.
> 
> Signed-off-by: Takeru Hayasaka <hayatake396@gmail.com>
> ---
> Takeru Hayasaka (3):
>       migration/postcopy: Extract page fault handler callback
>       migration/postcopy: Factor out uffd_setup_incoming() from postcopy setup
>       migration/ram: Split mapped-ram header and page loading
> 
>  migration/migration.h    |  5 +++
>  migration/postcopy-ram.c | 86 +++++++++++++++++++++++++++++++++++-------------
>  migration/postcopy-ram.h | 27 +++++++++++++++
>  migration/ram.c          | 52 +++++++++++++++++++++++++----
>  4 files changed, 142 insertions(+), 28 deletions(-)
> ---
> base-commit: 8e711856d7639cbffa51405f2cc2366e3d9e3a23
> change-id: 20260327-fast-snapshot-refactor-3c6bb472b777
> 
> Best regards,
> --  
> Takeru Hayasaka <hayatake396@gmail.com>
> 

-- 
Peter Xu

Hi Peter,

> Thanks for your interest and enthusiasm to the QEMU community. Said that,
> please hold off a bit on sending patches that enable fast snapshot load for
> now, even for preparations.
>
> The problem is, this topic, as announced, is to be developed by a GSoC
> student only later. We want to make sure this topic will be done during the
> GSoC period by the selected candidate, and we will also need to evalute the
> progress no matter who is doing it.
>
> I'm not sure if it's fair if any of the applicants start sending patches.
> I also don't hope to see multiple versions of impl floating around. IMHO
> it's slightly against how collaboration works upstream when we know there
> can be work collisions and we should avoid it from happening.

I understand. I was eager to demonstrate my enthusiasm for the
project, which led me to send these patches prematurely. I'll hold
off on any patches related to fast snapshot load, including
preparatory refactoring, until the GSoC period begins. I'll focus
on unrelated contributions in the meantime.

> Feel free to send whatever patches that do not have direct involvement with
> this specific topic.

Thank you, will do.

> When postcopy code is changed, I think it needs to be tested.
>
> Could you explain what do you mean by "userfaultfd, which was not available
> in my test environment"? Are you using Linux?

I apologize for the lack of rigor. I am on Linux. The postcopy tests
were skipped because I ran them as an unprivileged user
(vm.unprivileged_userfaultfd defaults to 0). I should have rerun
them with sudo. I've since confirmed the postcopy tests pass that way.

Thanks,
Takeru