[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-2.1] exec: fix migration with devices that u
From: |
Juan Quintela |
Subject: |
Re: [Qemu-devel] [PATCH for-2.1] exec: fix migration with devices that use address_space_rw |
Date: |
Tue, 22 Jul 2014 14:56:57 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
Paolo Bonzini <address@hidden> 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 <address@hidden>
> Signed-off-by: Paolo Bonzini <address@hidden>
Reviewed-by: Juan Quintela <address@hidden>
Paolo, are you doing the pull for this, or should I do it?
Thanks, Juan.