Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

microVM: write back dirty shared-mapping pages of host shares before every capture

Aperta
  • Qualcosa non va?
#555 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
22/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
linux
Ambito
infrastructure, operating-systems

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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 syncfs on 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.
Lingua principale
Python
Stelle
380
Fork
24
Merge medio
12h 3m
PR unite (30g)
292

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/nvx

Tutte le issue di microsoft/nvx

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.