QMP, Introduce xen-set-global-dirty-log command.

This command is used during a migration of a guest under Xen. It calls
cpu_physical_memory_set_dirty_tracking.

Backport of 39f42439d0629d3921629dc4b38e68df8f2f7b83

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
xen: Introduce xen_modified_memory.

This function is to be used during live migration. Every write access to the
guest memory should call this funcion so the Xen tools knows which pages are
dirty.

Backport of 910b38e4dc4c37683c8b821e75a7f4cf095e4b21

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
cpu_physical_memory_write_rom() needs to do TB invalidates

cpu_physical_memory_write_rom(), despite the name, can also be used to
write images into RAM - and will often be used that way if the machine
uses load_image_targphys() into RAM addresses.

However, cpu_physical_memory_write_rom(), unlike cpu_physical_memory_rw()
doesn't invalidate any cached TBs which might be affected by the region
written.

This was breaking reset (under full emu) on the pseries machine - we loaded
our firmware image into RAM, and while executing it rewrite the code at
the entry point (correctly causing a TB invalidate/refresh).  When we
reset the firmware image was reloaded, but the TB from the rewrite was
still active and caused us to get an illegal instruction trap.

This patch fixes the bug by duplicating the tb invalidate code from
cpu_physical_memory_rw() in cpu_physical_memory_write_rom().

Backport of original commit 0b57e287138728f72d88b06e69b970c5d745c44a

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
exec: Introduce helper to set dirty flags.

This new helper/hook is used in the next patch to add an extra call in a single
place.

Backport of 51d7a9eb2b64e787c90bea1027308087eac22065

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
exec, memory: Call to xen_modified_memory.

This patch add some calls to xen_modified_memory to notify Xen about dirtybits
during migration.

Backport of e226939de5814527a21396903b08c3d0ed989558

Note a call to xen_modify_memory has been added to qemu_ram_alloc_from_ptr
as the upstream version does:
  cpu_physical_memory_set_dirty_range(new_block->offset, size, 0xff);
and this function does not exist in 4.2.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
xen: Set the vram dirty when an error occurs.

If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
video ram. This case happens during migration.

Backport of 8aba7dc02d5660df7e7d8651304b3079908358be

This backport is less clean that it might be because there is no
memory_region_set_dirty that copes with more than one page in 4.2,
and the case where the call to xc_hvm_track_dirty_vram is
successful also needs to ensure xen_modified_memory is
called (which would on unstable have been done within
memory_region_set_dirty).

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Alex Bligh <alex@alex.org.uk>
xen: xen_sync_dirty_bitmap: attempt to fix SEGV

When xc_hvm_track_dirty_vram fails, iterate through pages based on
vram_offset and npages, rather than start_addr and size. DPRINTF
before the loop too.

[ Fixes a regression introduced by
  eccc68722696864fc4823f048c7be58d11281b97 - iwj ]

Signed-off-by: Alex Bligh <alex@alex.org.uk>
Tested-by: Ian Jackson <ian.jackson@eu.citrix.com>