On 09.02.2021 15:37, David Hildenbrand wrote:
On 21.01.21 16:24, andrey.gruzdev--- via wrote:
This patch series is a kind of 'rethinking' of Denis Plotnikov's
ideas he's
implemented in his series '[PATCH v0 0/4] migration: add background
snapshot'.
Currently the only way to make (external) live VM snapshot is using
existing
dirty page logging migration mechanism. The main problem is that it
tends to
produce a lot of page duplicates while running VM goes on updating
already
saved pages. That leads to the fact that vmstate image size is
commonly several
times bigger then non-zero part of virtual machine's RSS. Time
required to
converge RAM migration and the size of snapshot image severely depend
on the
guest memory write rate, sometimes resulting in unacceptably long
snapshot
creation time and huge image size.
This series propose a way to solve the aforementioned problems. This
is done
by using different RAM migration mechanism based on UFFD write
protection
management introduced in v5.7 kernel. The migration strategy is to
'freeze'
guest RAM content using write-protection and iteratively release
protection
for memory ranges that have already been saved to the migration stream.
At the same time we read in pending UFFD write fault events and save
those
pages out-of-order with higher priority.
Hi,
just stumbled over this, quick question:
I recently played with UFFD_WP and notices that write protection is
only effective on pages/ranges that have already pages populated (IOW:
!pte_none() in the kernel).
In case memory was never populated (or was discarded using e.g.,
madvice(DONTNEED)), write-protection will be skipped silently and you
won't get WP events for applicable pages.
So if someone writes to a yet unpoupulated page ("zero"), you won't
get WP events.
I can spot that you do a single uffd_change_protection() on the whole
RAMBlock.
How are you handling that scenario, or why don't you have to handle
that scenario?
Hi David,
I really wonder if such a problem exists.. If we are talking about a
write to an unpopulated page, we should get first page fault on
non-present page and populate it with protection bits from respective vma.
For UFFD_WP vma's page will be populated non-writable. So we'll get
another page fault on present but read-only page and go to handle_userfault.
--
Andrey Gruzdev, Principal Engineer
Virtuozzo GmbH +7-903-247-6397
virtuzzo.com
