| Message ID | 1242242474-7599-1-git-send-email-glommer@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Glauber Costa <glommer@redhat.com> [2009-05-13 14:22]: > In the call path of kvm_get_dirty_pages_log_range(), > its caller kvm_get_dirty_bitmap_cb() passes the > target_phys_addr_t both as start_addr and the offset. > So, using int will make dirty tracking over 4G fail > completely. Does this patch fix someting like 32-bit migration with >4G ? Seems like it might. > > Of course we should be using qemu types in > here, so please don't get me started on this. The whole > file is wrong already ;) > > Signed-off-by: Glauber Costa <glommer@redhat.com> > --- > qemu-kvm.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/qemu-kvm.c b/qemu-kvm.c > index f55cee8..27c37b5 100644 > --- a/qemu-kvm.c > +++ b/qemu-kvm.c > @@ -1201,7 +1201,7 @@ int kvm_physical_memory_set_dirty_tracking(int enable) > /* get kvm's dirty pages bitmap and update qemu's */ > static int kvm_get_dirty_pages_log_range(unsigned long start_addr, > unsigned char *bitmap, > - unsigned int offset, > + unsigned long offset, > unsigned long mem_size) > { > unsigned int i, j, n=0; > -- > 1.5.6.6 > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, May 13, 2009 at 5:23 PM, Ryan Harper <ryanh@us.ibm.com> wrote: > * Glauber Costa <glommer@redhat.com> [2009-05-13 14:22]: >> In the call path of kvm_get_dirty_pages_log_range(), >> its caller kvm_get_dirty_bitmap_cb() passes the >> target_phys_addr_t both as start_addr and the offset. >> So, using int will make dirty tracking over 4G fail >> completely. > > Does this patch fix someting like 32-bit migration with >4G ? Â Seems > like it might. it fixes general > 4G migration. I tested a 64-bit guest on a 64-bit host, and it does not work previous to this patch
Glauber Costa wrote: > In the call path of kvm_get_dirty_pages_log_range(), > its caller kvm_get_dirty_bitmap_cb() passes the > target_phys_addr_t both as start_addr and the offset. > So, using int will make dirty tracking over 4G fail > completely. > > Of course we should be using qemu types in > here, so please don't get me started on this. The whole > file is wrong already ;) > :-) > Signed-off-by: Glauber Costa <glommer@redhat.com> > Good candidate for stable too. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Glauber Costa wrote: > In the call path of kvm_get_dirty_pages_log_range(), > its caller kvm_get_dirty_bitmap_cb() passes the > target_phys_addr_t both as start_addr and the offset. > So, using int will make dirty tracking over 4G fail > completely. > > Applied, thanks. > Of course we should be using qemu types in > here, so please don't get me started on this. The whole > file is wrong already ;) > These callbacks are called from libkvm, which doesn't know much about qemu.
diff --git a/qemu-kvm.c b/qemu-kvm.c index f55cee8..27c37b5 100644 --- a/qemu-kvm.c +++ b/qemu-kvm.c @@ -1201,7 +1201,7 @@ int kvm_physical_memory_set_dirty_tracking(int enable) /* get kvm's dirty pages bitmap and update qemu's */ static int kvm_get_dirty_pages_log_range(unsigned long start_addr, unsigned char *bitmap, - unsigned int offset, + unsigned long offset, unsigned long mem_size) { unsigned int i, j, n=0;
In the call path of kvm_get_dirty_pages_log_range(), its caller kvm_get_dirty_bitmap_cb() passes the target_phys_addr_t both as start_addr and the offset. So, using int will make dirty tracking over 4G fail completely. Of course we should be using qemu types in here, so please don't get me started on this. The whole file is wrong already ;) Signed-off-by: Glauber Costa <glommer@redhat.com> --- qemu-kvm.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)