This patch series add support for stage2 hardware DBM, and it is only
used for dirty log for now.
It works well under some migration test cases, including VM with 4K
pages or 2M THP. I checked the SHA256 hash digest of all memory and
they keep same for source VM and destination VM, which means no dirty
pages is missed under hardware DBM.
However, there are some known issues not solved.
1. Some mechanisms that rely on "write permission fault" become invalid,
such as kvm_set_pfn_dirty and "mmap page sharing".
kvm_set_pfn_dirty is called in user_mem_abort when guest issues write
fault. This guarantees physical page will not be dropped directly when
host kernel recycle memory. After using hardware dirty management, we
have no chance to call kvm_set_pfn_dirty.
For "mmap page sharing" mechanism, host kernel will allocate a new
physical page when guest writes a page that is shared with other page
table entries. After using hardware dirty management, we have no chance
to do this too.
I need to do some survey on how stage1 hardware DBM solve these problems.
It helps if anyone can figure it out.
2. Page Table Modification Races: Though I have found and solved some data
races when kernel changes page table entries, I still doubt that there
are data races I am not aware of. It's great if anyone can figure them out.
3. Performance: Under Kunpeng 920 platform, for every 64GB memory, KVM
consumes about 40ms to traverse all PTEs to collect dirty log. It will
cause unbearable downtime for migration if memory size is too big. I will
try to solve this problem in Patch v1.