Hi all,
This patch series provide some fix to have migration working with Xen. The main
issue with Xen is that the guest RAM is not handle by QEMU.
So, first of all, the RAM will not be saved in the QEMU state file.
- For this, we can also unregister the ram_save_live function later in xen code
instead of having this extra "if xen" but I'm not sure of wish one would be
the best choice.
Then, during the initialisation that append before the migration, QEMU should
not try to allocate again the VRAM of the vga emulation, because it's already
there. (The guest RAM is restored before calling QEMU)
And last but not least, in QEMU with Xen, a call to set_memory (with different
address for start_addr and phys_offset) actually move the the memory, and the
only way to have a pointer to this memory is to ask a ptr with the new addr.
So, there is a patch that check for the right guest address to map.
There is probably a better way to do some of this.
Change since v1:
- rename xen_addr_actually_is to xen_phys_offset_to_gaddr.
- give phys_offset_to_gaddr as a pointer to map_cache_init
(no more global var in xen-all.c).
- call xen_phys_offset_to_gaddr only if the first try fail.
- also change a comment in the last patch.
Regards,
Anthony PERARD (5):
vl.c: Do not save RAM state when Xen is used.
xen mapcache: Check if a memory space has moved.
Introduce premigrate RunState.
xen: Change memory access behavior during migration.
vga-cirrus: Workaround during restore when using Xen.
hw/cirrus_vga.c | 16 +++++++++++++---
qapi-schema.json | 2 +-
vl.c | 10 ++++++++--
xen-all.c | 31 ++++++++++++++++++++++++++++++-
xen-mapcache.c | 22 +++++++++++++++++++---
xen-mapcache.h | 9 +++++++--
6 files changed, 78 insertions(+), 12 deletions(-)
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
This patch series provide some fix to have migration working with Xen. The main
issue with Xen is that the guest RAM is not handle by QEMU.
So, first of all, the RAM will not be saved in the QEMU state file.
- For this, we can also unregister the ram_save_live function later in xen code
instead of having this extra "if xen" but I'm not sure of wish one would be
the best choice.
Then, during the initialisation that append before the migration, QEMU should
not try to allocate again the VRAM of the vga emulation, because it's already
there. (The guest RAM is restored before calling QEMU)
And last but not least, in QEMU with Xen, a call to set_memory (with different
address for start_addr and phys_offset) actually move the the memory, and the
only way to have a pointer to this memory is to ask a ptr with the new addr.
So, there is a patch that check for the right guest address to map.
There is probably a better way to do some of this.
Change since v1:
- rename xen_addr_actually_is to xen_phys_offset_to_gaddr.
- give phys_offset_to_gaddr as a pointer to map_cache_init
(no more global var in xen-all.c).
- call xen_phys_offset_to_gaddr only if the first try fail.
- also change a comment in the last patch.
Regards,
Anthony PERARD (5):
vl.c: Do not save RAM state when Xen is used.
xen mapcache: Check if a memory space has moved.
Introduce premigrate RunState.
xen: Change memory access behavior during migration.
vga-cirrus: Workaround during restore when using Xen.
hw/cirrus_vga.c | 16 +++++++++++++---
qapi-schema.json | 2 +-
vl.c | 10 ++++++++--
xen-all.c | 31 ++++++++++++++++++++++++++++++-
xen-mapcache.c | 22 +++++++++++++++++++---
xen-mapcache.h | 9 +++++++--
6 files changed, 78 insertions(+), 12 deletions(-)
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel