On 22/03/21 10:17, Keqian Zhu wrote:
Hi Peter,
On 2021/3/11 4:33, Peter Xu wrote:
KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 is for KVM_CLEAR_DIRTY_LOG, which is only
useful for KVM_GET_DIRTY_LOG. Skip enabling it for kvm dirty ring.
More importantly, KVM_DIRTY_LOG_INITIALLY_SET will not wr-protect all the pages
initially, which is against how kvm dirty ring is used - there's no way for kvm
dirty ring to re-protect a page before it's notified as being written first
with a GFN entry in the ring! So when KVM_DIRTY_LOG_INITIALLY_SET is enabled
with dirty ring, we'll see silent data loss after migration.
I feel a little regret that dirty ring can not work with
KVM_DIRTY_LOG_INITIALLY_SET ...
With KVM_DIRTY_LOG_INITIALLY_SET, we can speedup dirty log start. More
important, we can
enable dirty log gradually. For write fault based dirty log, it greatly reduces
the side
effect of dirty log over guest.
I hope we can put forward another similar optimization under dirty ring mode. :)
Indeed, perhaps (even though KVM_GET_DIRTY_LOG does not make sense with
dirty ring) we could allow KVM_CLEAR_DIRTY_LOG.
Paolo
