Re: [RFC] virtio_pmem: enable live migration support

[David Hildenbrand <david@redhat.com>]

On 12.01.22 17:08, Pankaj Gupta wrote:
>>>> I mean, that would be fundamentally broken, because the fsync() would
>>>> corrupt the file. So I assume in a sane environment, the dst could only
>>>> have stale clean pagecache pages. And we'd have to get rid of these to
>>>> re-read everything from file.
>>>
>>> In case of write back cache mode, we could still have stale dirty
>>> pages at the destination
>>> host and destination fsync is not the right thing to do. We need to
>>> invalidate these pages
>>> (Can we invalidate dirty pages resident in page cache with
>>> POSIX_FADV_DONTNEED as
>>> well?) man pages say, we cannot (unless i misunderstood it).
>>>
>>
>> I think you'd have to fsync + POSIX_FADV_DONTNEED. But I am still
>> confused how we could end up with dirty pagecache pages on the
>> destination. In my opinion, there should only be clean pagecache pages
>> -- can someone enlighten me? :)
> 
> because of activity on the page cache pages corresponding to mmap region
> in the past which is not synced yet or not reclaimed yet. Maybe this
> is hypothetical
> or not possible, happy to learn?

Right, but assume the following *sane*

#1 H0 starts and runs VM.
#2 H0 migrates VM to H1.
#3 H1 runs VM.
#4 H1 migrates VM to H0.
#5 H0 runs VM.

We'd expect a proper fsync during #2, writing back any dirty pages to
the memory backend. Otherwise, #3 would already be broken. Similarly,
we'd expect a proper fsync during #4.

I assume during #4 we could find clean pagecache pages that are actually
invalid, because the underlying file was changed by H1. So we have to
make sure to invalidate all pagecache pages (all clean).

-- 
Thanks,

David / dhildenb