kvm: Some more trivial fixes for clear dirty log
cover kvm: Some more trivial fixes for clear dirty log
Two issues I've noticed when I'm drafting the QEMU support of it. With these two patches applied the QEMU binary (with the clear dirty log supported [1]) can migrate correctly otherwise the migration can stall forever if with/after heavy memory workload.
Please have a look, thanks.
[1] https://github.com/xzpeter/qemu/tree/kvm-clear-dirty-log
Peter Xu (2):
kvm: Fix the bitmap range to copy during clear dirty
kvm: Fix loop of clear dirty with off-by-one
virt/kvm/kvm_main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Signature · 1 line
2.17.1
PATCH 1/2 kvm: Fix the bitmap range to copy during clear dirty
kvm_dirty_bitmap_bytes() will return the size of the dirty bitmap of the memslot rather than the size of bitmap passed over from the ioctl. Here for KVM_CLEAR_DIRTY_LOG we should only copy exactly the size of bitmap that covers kvm_clear_dirty_log.num_pages.
--- virt/kvm/kvm_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
virt/kvm/kvm_main.c +1 -1
@@ -1251,7 +1251,7 @@ int kvm_clear_dirty_log_protect(struct kvm *kvm,if (!dirty_bitmap)return -ENOENT ; - n =kvm_dirty_bitmap_bytes (memslot); + n =ALIGN (log->num_pages,BITS_PER_LONG ) /8 ; if (log->first_page > memslot->npages || log->num_pages > memslot->npages - log->first_page ||
Signature · 1 line
2.17.1
PATCH 2/2 kvm: Fix loop of clear dirty with off-by-one
In reply to Peter XuJust imaging the case where num_pages < BITS_PER_LONG, then the loop will be skipped while it shouldn't.
--- virt/kvm/kvm_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
virt/kvm/kvm_main.c +2 -2
@@ -1264,8 +1264,8 @@ int kvm_clear_dirty_log_protect(struct kvm *kvm,return -EFAULT ;spin_lock (&kvm->mmu_lock); -for (offset = log->first_page, - i = offset /BITS_PER_LONG , n = log->num_pages /BITS_PER_LONG ; n--; +for (offset = log->first_page, i = offset /BITS_PER_LONG , + n = (log->num_pages /BITS_PER_LONG +1 ); n--; i++, offset +=BITS_PER_LONG ) {unsigned long mask = *dirty_bitmap_buffer++;atomic_long_t *p = (atomic_long_t *) &dirty_bitmap[i];
Signature · 1 line
2.17.1
Paolo Bonzini
maintainerQuoted 7 lines · Peter Xu
Two issues I've noticed when I'm drafting the QEMU support of it. With these two patches applied the QEMU binary (with the clear dirty log supported [1]) can migrate correctly otherwise the migration can stall forever if with/after heavy memory workload.
Please have a look, thanks.
Quoted 9 lines
[1] https://github.com/xzpeter/qemu/tree/kvm-clear-dirty-log
Peter Xu (2):
kvm: Fix the bitmap range to copy during clear dirty
kvm: Fix loop of clear dirty with off-by-onevirt/kvm/kvm_main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Looks good, but this is a blocker for using this feature in userspace. I think we should change the capability name and number.
Paolo
Quoted 14 lines · Paolo Bonzini
Quoted 13 lines · Peter Xu
Two issues I've noticed when I'm drafting the QEMU support of it. With these two patches applied the QEMU binary (with the clear dirty log supported [1]) can migrate correctly otherwise the migration can stall forever if with/after heavy memory workload.
Please have a look, thanks.
[1] https://github.com/xzpeter/qemu/tree/kvm-clear-dirty-log
Peter Xu (2):
kvm: Fix the bitmap range to copy during clear dirty
kvm: Fix loop of clear dirty with off-by-one
Quoted 6 lines
Quoted 3 lines
virt/kvm/kvm_main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)Looks good, but this is a blocker for using this feature in userspace. I think we should change the capability name and number.
Ok, let me add another patch for it. Also I probably have made a mistake too in patch 2 (it's not really off-by-one, but it should be a DIV_ROUND_UP I think...). I'll post a new version soon.
Thanks,
Signature · 1 line
Peter Xu