Paolo Bonzini <pbonz...@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 <dgilb...@redhat.com> > Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Reviewed-by: Juan Quintela <quint...@redhat.com> Paolo, are you doing the pull for this, or should I do it? Thanks, Juan.
