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
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
* Glauber Costa glom...@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
On Wed, May 13, 2009 at 5:23 PM, Ryan Harper ry...@us.ibm.com wrote:
* Glauber Costa glom...@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
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