[Qemu-devel] [PATCH] kvm: Mark full address range dirty on live migration start

[Qemu-devel] [PATCH] kvm: Mark full address range dirty on live migration start

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

As Avi correctly noted, last_ram_offset does not mark the last physical
RAM address the guest may see (due to non-continuous memory regions).
Ensure that we catch them all by marking the full possible address range
dirty.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---

 targphys.h |    2 ++
 vl.c       |    2 +-
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/targphys.h b/targphys.h
index 81a9c37..99ab23c 100644
--- a/targphys.h
+++ b/targphys.h
@@ -12,9 +12,11 @@
 
 #if TARGET_PHYS_ADDR_BITS == 32
 typedef uint32_t target_phys_addr_t;
+#define TARGET_PHYS_ADDR_MAX UINT32_MAX
 #define TARGET_FMT_plx "%08x"
 #elif TARGET_PHYS_ADDR_BITS == 64
 typedef uint64_t target_phys_addr_t;
+#define TARGET_PHYS_ADDR_MAX UINT64_MAX
 #define TARGET_FMT_plx "%016" PRIx64
 #endif
 #endif
diff --git a/vl.c b/vl.c
index 2c1f0e0..090c83d 100644
--- a/vl.c
+++ b/vl.c
@@ -3232,7 +3232,7 @@ static int ram_save_live(QEMUFile *f, int stage, void *opaque)
 {
     ram_addr_t addr;
 
-    if (cpu_physical_sync_dirty_bitmap(0, last_ram_offset) != 0) {
+    if (cpu_physical_sync_dirty_bitmap(0, TARGET_PHYS_ADDR_MAX) != 0) {
         qemu_file_set_error(f);
         return 0;
     }


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] [PATCH] kvm: Mark full address range dirty on live migration start

[Glauber Costa]

On Fri, May 22, 2009 at 11:51:45PM +0200, Jan Kiszka wrote:
> As Avi correctly noted, last_ram_offset does not mark the last physical
> RAM address the guest may see (due to non-continuous memory regions).
> Ensure that we catch them all by marking the full possible address range
> dirty.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Indeed, we already do something in that lines in qemu-kvm tree, 
in a place that does not apply for  It makes a lot of sense. Just
maybe you could just -1UL instead of defining a new constant, but I don't
really care.

As soon as this is applied to master, I'll pick it for stable too.

Thanks

Re: [Qemu-devel] [PATCH] kvm: Mark full address range dirty on live migration start

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

Glauber Costa wrote:
> On Fri, May 22, 2009 at 11:51:45PM +0200, Jan Kiszka wrote:
>> As Avi correctly noted, last_ram_offset does not mark the last physical
>> RAM address the guest may see (due to non-continuous memory regions).
>> Ensure that we catch them all by marking the full possible address range
>> dirty.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> Indeed, we already do something in that lines in qemu-kvm tree, 
> in a place that does not apply for  It makes a lot of sense. Just
> maybe you could just -1UL instead of defining a new constant, but I don't
> really care.

I intentionally made this verbose.

> 
> As soon as this is applied to master, I'll pick it for stable too.

Migration for KVM would be a new feature for stable. It requires a new
CPU save/restore format (V9). Do think that qualifies it for stable.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] [PATCH] kvm: Mark full address range dirty on live migration start

[Paul Brook]

On Saturday 23 May 2009, Glauber Costa wrote:
> On Fri, May 22, 2009 at 11:51:45PM +0200, Jan Kiszka wrote:
> > As Avi correctly noted, last_ram_offset does not mark the last physical
> > RAM address the guest may see (due to non-continuous memory regions).
> > Ensure that we catch them all by marking the full possible address range
> > dirty.
> >
> > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>
> Indeed, we already do something in that lines in qemu-kvm tree,
> in a place that does not apply for  It makes a lot of sense. Just
> maybe you could just -1UL instead of defining a new constant, but I don't
> really care.

-1ul is wrong. -1 is correct.

Paul