Re: [Qemu-devel] [PATCH for-2.1] exec: fix migration with devices that use address_space_rw

[Juan Quintela <quintela@redhat.com>]

Paolo Bonzini <pbonzini@redhat.com> wrote:
> Devices that use address_space_rw to write large areas to memory
> (as opposed to address_space_map/unmap) were broken with respect
> to migration since fe680d0 (exec: Limit translation limiting in
> address_space_translate to xen, 2014-05-07).  Such devices include
> IDE CD-ROMs.
>
> The reason is that invalidate_and_set_dirty (called by address_space_rw
> but not address_space_map/unmap) was only setting the dirty bit for
> the first page in the translation.
>
> To fix this, introduce cpu_physical_memory_set_dirty_range_nocode that
> is the same as cpu_physical_memory_set_dirty_range except it does not
> muck with the DIRTY_MEMORY_CODE bitmap.  This function can be used if
> the caller invalidates translations with tb_invalidate_phys_page_range.
>
> There is another difference between cpu_physical_memory_set_dirty_range
> and cpu_physical_memory_set_dirty_flag; the former includes a call
> to xen_modified_memory.  This is handled separately in
> invalidate_and_set_dirty, and is not needed in other callers of
> cpu_physical_memory_set_dirty_range_nocode, so leave it alone.
>
> Just one nit: now that invalidate_and_set_dirty takes care of handling
> multiple pages, there is no need for address_space_unmap to wrap it
> in a loop.  In fact that loop would now be O(n^2).
>
> Reported-by: Dave Gilbert <dgilbert@redhat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>

Paolo, are you doing the pull for this, or should I do it?

Thanks, Juan.