microVM: write back dirty shared-mapping pages of host shares before every capture
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 22/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- linux
- Domain
- infrastructure, operating-systems
Research direction
Start with guest/common/nvx-snapshot, where the sync after the cgroup freeze runs only for paired-scratch captures, and with the virtio-fs section of doc/design/machine-and-device-abi.md plus 3.6.8 and 3.6.9 of the architecture guide. Done means every capture, including blockless and fresh-scratch ones, writes back dirty shared-mapping pages of live host shares before the boundary, with a test that dirties a shared mapping before a blockless capture and checks the restore does not write back to the host file. The design choice between agent-side syncfs and a device-side refusal needs maintainer input first.
Written by the indexing model from the issue text.
Description
Summary
A restored guest continues with captured memory, including the guest page cache. The microVM virtio-fs device grants shared mappings of direct-I/O files, which the guest kernel requests (Linux 6.6 and newer; the guest kernel is 6.18), so pages of shared memory mappings of files in a live host share are cached in guest RAM and written back to the host through ordinary write requests (section 3.6.1 of the architecture guide in #529).
Only a capture with paired scratch writes dirty pages back before the boundary: guest/common/nvx-snapshot runs sync after it freezes the workload cgroup, and only in that case. A blockless capture or a fresh-scratch capture leaves dirty shared-mapping pages in captured memory. After a restore, the guest kernel writes those pages back to the live host file, overwriting any change that the host made to the same range since the capture. Every restore of one snapshot attaches the same live host files, so every clone writes the same capture-time pages back to one host file.
The architecture guide now describes this exception in 3.6.8 and 3.6.9; this issue tracks removing the hazard.
Intended behavior
Every capture writes back the dirty pages of shared mappings on the host shares before the boundary, so a snapshot carries no unwritten file data for a live host file, and no restore writes capture-time data back to one.
Options
- Have the guest agents write back dirty file pages before every capture that has a live host share, for example with
syncfson the host-share mounts, after they stop the workload from dirtying further pages. - Have the device refuse capture while the guest holds dirty shared-mapping pages of a live share; the device cannot observe them, so this needs a guest-side check.
Tasks
- Write back dirty shared-mapping pages of the host shares before every capture, not only paired-scratch captures, and define how a workload is kept from dirtying pages between the write-back and the boundary when it is not frozen.
- Add coverage: a workload that dirties a shared mapping of a live share before a blockless capture, and a restore that must not write capture-time data back to the host file.
- Update the capture and restore parts of the virtio-fs section of
doc/design/machine-and-device-abi.md, and 3.6.8 and 3.6.9 of the architecture guide.
- Dominant language
- Python
- Stars
- 380
- Forks
- 24
- Avg merge
- 12h 3m
- Merged PRs (30d)
- 292
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/nvx
-
bug-hunt confirmed
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
documentation
Difficulty 5/5 Over a week Newbie friendliness 8/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 15/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 30/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 18/100
Maintainers usually reply within 1 day
Similar issues
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
btclib-org/btclib-node#1955 ·
Maintainers usually reply within 1 day
-
documentation v0.9.2
Difficulty 2/5 Half a day Newbie friendliness 72/100
khuisman/mcp-gee-sweet#1033 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
ossf/cve-bin-tool#5966 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 2 days
-
write_iceberg ignores the table's write.parquet.compression-codec propertyPossibly taken @YuangGao claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Eventual-Inc/Daft#7606 ·
Maintainers usually reply within 1 day