[Qemu-commits] [qemu/qemu] 688686: exec: fix migration with devices that use address_...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 6886867e9880830d735d8ae6f6cc63ed9eb2be0c
      
https://github.com/qemu/qemu/commit/6886867e9880830d735d8ae6f6cc63ed9eb2be0c
  Author: Paolo Bonzini <address@hidden>
  Date:   2014-07-22 (Tue, 22 Jul 2014)

  Changed paths:
    M exec.c
    M include/exec/ram_addr.h

  Log Message:
  -----------
  exec: fix migration with devices that use address_space_rw

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>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Tested-by: Gerd Hoffmann <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: dc54e2525389e903cee2b847cf761b5d857f75cb
      
https://github.com/qemu/qemu/commit/dc54e2525389e903cee2b847cf761b5d857f75cb
  Author: Chen Gang <address@hidden>
  Date:   2014-07-22 (Tue, 22 Jul 2014)

  Changed paths:
    M kvm-all.c

  Log Message:
  -----------
  kvm-all: Use 'tmpcpu' instead of 'cpu' in sub-looping to avoid 'cpu' be NULL

If kvm_arch_remove_sw_breakpoint() in CPU_FOREACH() always be fail, it
will let 'cpu' NULL. And the next kvm_arch_remove_sw_breakpoint() in
QTAILQ_FOREACH_SAFE() will get NULL parameter for 'cpu'.

And kvm_arch_remove_sw_breakpoint() can assumes 'cpu' must never be NULL,
so need define additional temporary variable for 'cpu' to avoid the case.

Cc: address@hidden
Signed-off-by: Chen Gang <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 25af8e6b6106f47f5ee276545fcab47cefa67ba1
      
https://github.com/qemu/qemu/commit/25af8e6b6106f47f5ee276545fcab47cefa67ba1
  Author: Peter Maydell <address@hidden>
  Date:   2014-07-22 (Tue, 22 Jul 2014)

  Changed paths:
    M exec.c
    M include/exec/ram_addr.h
    M kvm-all.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging

One of the two pending migration fix, and a small KVM patch.

# gpg: Signature made Tue 22 Jul 2014 11:49:30 BST using RSA key ID 9B4D86F2
# gpg: Can't check signature: public key not found

* remotes/bonzini/tags/for-upstream:
  kvm-all: Use 'tmpcpu' instead of 'cpu' in sub-looping to avoid 'cpu' be NULL
  exec: fix migration with devices that use address_space_rw

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/35858955e6c6...25af8e6b6106