Re: [PATCH v13 0/5] UFFD write-tracking migration/snapshots

[David Hildenbrand]

> Am 19.02.2021 um 23:47 schrieb Peter Xu <peterx@redhat.com>:
> 
> On Fri, Feb 19, 2021 at 10:20:42PM +0100, David Hildenbrand wrote:
>>> A shiver just went down my spine. Please don‘t just for the sake of 
>>> creating a snapshot.
>>> 
>>> (Just imagine you don‘t have a shared zeropage...)
>> 
>> ... and I just remembered we read all memory either way. Gah.
>> 
>> I have some patches to make snapshots fly with virtio-mem so exactly that 
>> won‘t happen. But they depend on vfio support, so it might take a while.
> 
> Sorry I can't really follow.
> 

Live snapshotting ends up reading all guest memory (dirty bitmap starts with 
all 1s), which is not what we want for virtio-mem - we don’t want to read and 
migrate memory that has been discarded and has no stable content.

For ordinary migration we use the guest page hint API to clear bits in the 
dirty bitmap after dirty bitmap sync. Well, if we don‘t do bitmap syncs we‘ll 
never clear any dirty bits. That‘s the problem.

> It'll be great if virtio-mem won't have similar problem with live snapshot
> finally.  Is that idea applicable to balloon too, then?

The idea is to reuse the RamDiscardMgr as to be introduced with vfio support to 
teach migration code which parts of specific RAMBlock never to migrate. It 
avoids the hack with reusing the guest page hint API.

As virtio-balloon is not applicable to RamDiscardMgr (and virtio-balloon has no 
memory about what has been inflated) it won‘t affect virtio-balloon.

> 
> -- 
> Peter Xu
>