You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(api): POST /uffd/wp endpoint for snapshot-side WP
Add a Firecracker API endpoint that lets an external tool
(forkd-controller for the v0.4 live-fork path) arm UFFD-WP on
guest memory. FC creates the userfaultfd, issues UFFDIO_REGISTER
with WRITE_PROTECT mode against every guest_memory region, then
connects to the caller-supplied UDS and ships the fd via
SCM_RIGHTS along with a JSON descriptor of the regions.
Why FC has to be the one creating the uffd: UFFDIO_REGISTER can
only register VMAs in the same process that called
userfaultfd(2). KVM runs inside FC's process; guest writes go
through FC's EPT/VMA. A controller-side uffd registered against
its own mmap would never see KVM writes. Modeling on FC's
existing restore-side Uffd backend (which sends the fd from FC
to the page-fault handler), this new endpoint flips the direction
for the snapshot side.
Request shape:
PUT /uffd/wp
{"socket": "/run/forkd-controller/.../wp.sock"}
-> 204 No Content
-> SCM_RIGHTS message on the socket carrying the uffd fd plus
a JSON array of GuestRegionUffdMapping describing what was
registered (matches the existing restore-side handshake).
Patch covers five files because SnapshotType's pre-existing
exhaustive matches force a touch in each:
- src/vmm/src/vmm_config/wp_uffd.rs (new) - request params
- src/vmm/src/persist.rs - setup_wp_uffd + error type
- src/vmm/src/rpc_interface.rs - VmmAction variant + dispatch
- src/firecracker/src/api_server/mod.rs - metric branch
- src/firecracker/src/api_server/request/wp_uffd.rs (new) - route parser
- src/firecracker/src/api_server/parsed_request.rs - routing
- src/firecracker/src/api_server/request/mod.rs - mod declaration
- src/vmm/Cargo.toml - userfaultfd "linux5_7" feature
End-to-end smoke test (via a memfd-backed restore so the WP target
VMA is shmem, not ext4):
/snapshot/load -> 204
FC mmap: /memfd:forkd-wp-test (deleted), 512 MiB, MAP_SHARED
/uffd/wp -> 204
Receiver got: 1 region (size=512MiB, page=4KiB), fd -> anon_inode:[userfaultfd]
Note: UFFD_WP requires shmem-backed (or anon) VMAs, not ext4
file-backed. Hitting this endpoint against a snapshot restored
with backend_type=File/backend_path=<ext4 file> returns
EINVAL on UFFDIO_REGISTER — the kernel correctly refuses to WP
a file-backed VMA. forkd-controller's v0.4 path goes through
memfd (Phase 5b: MemoryBackend::MemfdShared), so this is fine
for the intended caller.
0 commit comments