From: Junyan He
Because we need to make sure the pmem kind memory data is synced
after migration, we choose to call pmem_persist() when the migration
finish. This will make sure the data of pmem is safe and will not
lose if power is off.
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
From: Junyan He
The nvdimm kind memory does not support post copy now.
We disable post copy if we have nvdimm memory and print some
log hint to user.
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Igor Mammedov
---
migration/ram.c | 9 +
1 file changed, 9
From: Junyan He
Guest writes to vNVDIMM labels are intercepted and performed on the
backend by QEMU. When the backend is a real persistent memort, QEMU
needs to take proper operations to ensure its write persistence on the
persistent memory. Otherwise, a host power failure may result in the
loss
From: Junyan He
When QEMU emulates vNVDIMM labels and migrates vNVDIMM devices, it
needs to know whether the backend storage is a real persistent memory,
in order to decide whether special operations should be performed to
ensure the data persistence.
This boolean option 'pmem' allow
From: Junyan He
We need to use these flags in other files rather than just in exec.c,
For example, RAM_SHARED should be used when create a ram block from file.
We expose them the exec/memory.h
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Igor Mammedov
Reviewed-by
From: Junyan He
As more flag parameters besides the existing 'share' are going to be
added to following functions
memory_region_init_ram_from_file
qemu_ram_alloc_from_fd
qemu_ram_alloc_from_file
let's switch them to use the 'flags' parameters so as to ease future
flag
From: Junyan He
Add a pair of configure options --{enable,disable}-libpmem to control
whether QEMU is compiled with PMDK libpmem [1].
QEMU may write to the host persistent memory (e.g. in vNVDIMM label
emulation and live migration), so it must take the proper operations
to ensure the
From: Junyan He
QEMU writes to vNVDIMM backends in the vNVDIMM label emulation and live
migration.
If the backend is on the persistent memory, QEMU needs to take proper
operations to
ensure its writes persistent on the persistent memory. Otherwise, a host power
failure
may result in the loss
From: Junyan He
Because we need to make sure the pmem kind memory data is synced
after migration, we choose to call pmem_persist() when the migration
finish. This will make sure the data of pmem is safe and will not
lose if power is off.
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
From: Junyan He
The nvdimm kind memory does not support post copy now.
We disable post copy if we have nvdimm memory and print some
log hint to user.
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Igor Mammedov
---
migration/ram.c | 9 +
1 file changed, 9
From: Junyan He
Add a pair of configure options --{enable,disable}-libpmem to control
whether QEMU is compiled with PMDK libpmem [1].
QEMU may write to the host persistent memory (e.g. in vNVDIMM label
emulation and live migration), so it must take the proper operations
to ensure the
From: Junyan He
Guest writes to vNVDIMM labels are intercepted and performed on the
backend by QEMU. When the backend is a real persistent memort, QEMU
needs to take proper operations to ensure its write persistence on the
persistent memory. Otherwise, a host power failure may result in the
loss
From: Junyan He
QEMU writes to vNVDIMM backends in the vNVDIMM label emulation and live
migration.
If the backend is on the persistent memory, QEMU needs to take proper
operations to
ensure its writes persistent on the persistent memory. Otherwise, a host power
failure
may result in the loss
From: Junyan He
When QEMU emulates vNVDIMM labels and migrates vNVDIMM devices, it
needs to know whether the backend storage is a real persistent memory,
in order to decide whether special operations should be performed to
ensure the data persistence.
This boolean option 'pmem' allow
From: Junyan He
We need to use these flags in other files rather than just in exec.c,
For example, RAM_SHARED should be used when create a ram block from file.
We expose them the exec/memory.h
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Igor Mammedov
---
exec.c
From: Junyan He
As more flag parameters besides the existing 'share' are going to be
added to following functions
memory_region_init_ram_from_file
qemu_ram_alloc_from_fd
qemu_ram_alloc_from_file
let's switch them to use the 'flags' parameters so as to ease future
flag
From: Junyan He
The nvdimm kind memory does not support post copy now.
We disable post copy if we have nvdimm memory and print some
log hint to user.
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Igor Mammedov
---
migration/ram.c | 9 +
1 file changed, 9
From: Junyan He
Because we need to make sure the pmem kind memory data is synced
after migration, we choose to call pmem_persist() when the migration
finish. This will make sure the data of pmem is safe and will not
lose if power is off.
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
From: Junyan He
When QEMU emulates vNVDIMM labels and migrates vNVDIMM devices, it
needs to know whether the backend storage is a real persistent memory,
in order to decide whether special operations should be performed to
ensure the data persistence.
This boolean option 'pmem' allow
From: Junyan He
Guest writes to vNVDIMM labels are intercepted and performed on the
backend by QEMU. When the backend is a real persistent memort, QEMU
needs to take proper operations to ensure its write persistence on the
persistent memory. Otherwise, a host power failure may result in the
loss
From: Junyan He
As more flag parameters besides the existing 'share' are going to be
added to following functions
memory_region_init_ram_from_file
qemu_ram_alloc_from_fd
qemu_ram_alloc_from_file
let's switch them to use the 'flags' parameters so as to ease future
flag
From: Junyan He
Add a pair of configure options --{enable,disable}-libpmem to control
whether QEMU is compiled with PMDK libpmem [1].
QEMU may write to the host persistent memory (e.g. in vNVDIMM label
emulation and live migration), so it must take the proper operations
to ensure the
From: Junyan He
QEMU writes to vNVDIMM backends in the vNVDIMM label emulation and
live migration. If the backend is on the persistent memory, QEMU needs
to take proper operations to ensure its writes persistent on the
persistent memory. Otherwise, a host power failure may result in the
loss
From: Junyan He
We need to use these flags in other files rather than just in exec.c,
For example, RAM_SHARED should be used when create a ram block from file.
We expose them the exec/memory.h
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Igor Mammedov
---
exec.c
From: Junyan He
Add a pair of configure options --{enable,disable}-libpmem to control
whether QEMU is compiled with PMDK libpmem [1].
QEMU may write to the host persistent memory (e.g. in vNVDIMM label
emulation and live migration), so it must take the proper operations
to ensure the
From: Junyan He
When QEMU emulates vNVDIMM labels and migrates vNVDIMM devices, it
needs to know whether the backend storage is a real persistent memory,
in order to decide whether special operations should be performed to
ensure the data persistence.
This boolean option 'pmem' allow
From: Junyan He
Because we need to make sure the pmem kind memory data is synced
after migration, we choose to call pmem_persist() when the migration
finish. This will make sure the data of pmem is safe and will not
lose if power is off.
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
From: Junyan He
We need to use these flags in other files rather than just in exec.c,
For example, RAM_SHARED should be used when create a ram block from file.
We expose them the exec/memory.h
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Igor Mammedov
---
exec.c
From: Junyan He
Guest writes to vNVDIMM labels are intercepted and performed on the
backend by QEMU. When the backend is a real persistent memort, QEMU
needs to take proper operations to ensure its write persistence on the
persistent memory. Otherwise, a host power failure may result in the
loss
From: Junyan He
QEMU writes to vNVDIMM backends in the vNVDIMM label emulation and
live migration. If the backend is on the persistent memory, QEMU needs
to take proper operations to ensure its writes persistent on the
persistent memory. Otherwise, a host power failure may result in the
loss
From: Junyan He
As more flag parameters besides the existing 'share' are going to be
added to following functions
memory_region_init_ram_from_file
qemu_ram_alloc_from_fd
qemu_ram_alloc_from_file
let's switch them to use the 'flags' parameters so as to ease future
flag
From: Junyan He
The nvdimm kind memory does not support post copy now.
We disable post copy if we have nvdimm memory and print some
log hint to user.
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Igor Mammedov
---
migration/ram.c | 9 +
1 file changed, 9
From: Junyan He
When QEMU emulates vNVDIMM labels and migrates vNVDIMM devices, it
needs to know whether the backend storage is a real persistent memory,
in order to decide whether special operations should be performed to
ensure the data persistence.
This boolean option 'pmem' allow
From: Junyan He
When QEMU emulates vNVDIMM labels and migrates vNVDIMM devices, it
needs to know whether the backend storage is a real persistent memory,
in order to decide whether special operations should be performed to
ensure the data persistence.
This boolean option 'pmem' allow
hint or warning acceptable?
From: Qemu-devel on behalf of
Junyan He
Sent: Tuesday, June 12, 2018 3:27:38 PM
To: Igor Mammedov
Cc: Haozhong Zhang; xiaoguangrong.e...@gmail.com; crosthwaite.pe...@gmail.com;
m...@redhat.com; qemu-devel@nongnu.org; dgilb...@redhat
tate pmem=force for testing purposes.
I think we can print a warning message to give user a hint, it can really help
user
when they mis-configure.
From: Qemu-devel on behalf of
Igor Mammedov
Sent: Tuesday, June 12, 2018 2:55:46 PM
To: Junyan He
Cc: Haozh
...@gmail.com; crosthwaite.pe...@gmail.com;
m...@redhat.com; qemu-devel@nongnu.org; dgilb...@redhat.com;
quint...@redhat.com; Junyan He; stefa...@redhat.com; pbonz...@redhat.com;
r...@twiddle.net; ehabk...@redhat.com
Subject: Re: [Qemu-devel] [PATCH V6 0/7] nvdimm: guarantee persistence of QEMU
From: Junyan He
Because we need to make sure the pmem kind memory data is synced
after migration, we choose to call pmem_persist() when the migration
finish. This will make sure the data of pmem is safe and will not
lose if power is off.
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
From: Junyan He
The nvdimm kind memory does not support post copy now.
We disable post copy if we have nvdimm memory and print some
log hint to user.
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
---
migration/ram.c | 9 +
1 file changed, 9 insertions(+)
diff --git a
From: Junyan He
Guest writes to vNVDIMM labels are intercepted and performed on the
backend by QEMU. When the backend is a real persistent memort, QEMU
needs to take proper operations to ensure its write persistence on the
persistent memory. Otherwise, a host power failure may result in the
loss
From: Junyan He
QEMU writes to vNVDIMM backends in the vNVDIMM label emulation and
live migration. If the backend is on the persistent memory, QEMU needs
to take proper operations to ensure its writes persistent on the
persistent memory. Otherwise, a host power failure may result in the
loss the
From: Junyan He
Add a pair of configure options --{enable,disable}-libpmem to control
whether QEMU is compiled with PMDK libpmem [1].
QEMU may write to the host persistent memory (e.g. in vNVDIMM label
emulation and live migration), so it must take the proper operations
to ensure the
From: Junyan He
When QEMU emulates vNVDIMM labels and migrates vNVDIMM devices, it
needs to know whether the backend storage is a real persistent memory,
in order to decide whether special operations should be performed to
ensure the data persistence.
This boolean option 'pmem' allow
From: Junyan He
As more flag parameters besides the existing 'share' are going to be
added to following functions
memory_region_init_ram_from_file
qemu_ram_alloc_from_fd
qemu_ram_alloc_from_file
let's switch them to use the 'flags' parameters so as to ease fu
From: Junyan He
We need to use these flags in other files rather than just in exec.c,
For example, RAM_SHARED should be used when create a ram block from file.
We expose them the exec/memory.h
Signed-off-by: Junyan He
Reviewed-by: Stefan Hajnoczi
---
exec.c| 20
te.pe...@gmail.com; m...@redhat.com;
dgilb...@redhat.com; ehabk...@redhat.com; quint...@redhat.com; Junyan He;
stefa...@redhat.com; pbonz...@redhat.com; imamm...@redhat.com; r...@twiddle.net
Subject: [Qemu-devel] [PATCH V6 RESEND 7/7] migration/ram: ensure write
persistence on loading all data to PMEM.
From: Junyan He
Because we need to make sure the pmem kind memory data is synced
after migration, we choose to call pmem_persist() when the migration
finish. This will make sure the data of pmem is safe and will not
lose if power is off.
Signed-off-by: Junyan He
---
include/qemu/pmem.h | 1
59:24 AM
To: Junyan He
Cc: Kevin Wolf; qemu block; qemu-devel@nongnu.org; Stefan Hajnoczi; Max Reitz
Subject: Re: [Qemu-devel] [Qemu-block] Some question about savem/qcow2
incremental snapshot
Hi Junyan,
AFAICU you are trying to utilize qcow2 capabilities to do incremental
snapshot. As I under
From: Junyan He
Because we need to make sure the pmem kind memory data is synced
after migration, we choose to call pmem_persist() when the migration
finish. This will make sure the data of pmem is safe and will not
lose if power is off.
Signed-off-by: Junyan He
---
include/qemu/pmem.h | 1
From: Junyan He
Because we need to make sure the pmem kind memory data is synced
after migration, we choose to call pmem_persist() when the migration
finish. This will make sure the data of pmem is safe and will not
lose if power is off.
Signed-off-by: Junyan He
---
include/qemu/pmem.h | 1
From: Junyan He
Guest writes to vNVDIMM labels are intercepted and performed on the
backend by QEMU. When the backend is a real persistent memort, QEMU
needs to take proper operations to ensure its write persistence on the
persistent memory. Otherwise, a host power failure may result in the
loss
From: Junyan He
The nvdimm kind memory does not support post copy now.
We disable post copy if we have nvdimm memory and print some
log hint to user.
Signed-off-by: Junyan He
---
migration/ram.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/migration/ram.c b/migration/ram.c
From: Junyan He
When QEMU emulates vNVDIMM labels and migrates vNVDIMM devices, it
needs to know whether the backend storage is a real persistent memory,
in order to decide whether special operations should be performed to
ensure the data persistence.
This boolean option 'pmem' allow
From: Junyan He
Add a pair of configure options --{enable,disable}-libpmem to control
whether QEMU is compiled with PMDK libpmem [1].
QEMU may write to the host persistent memory (e.g. in vNVDIMM label
emulation and live migration), so it must take the proper operations
to ensure the
From: Junyan He
As more flag parameters besides the existing 'share' are going to be
added to following functions
memory_region_init_ram_from_file
qemu_ram_alloc_from_fd
qemu_ram_alloc_from_file
let's switch them to use the 'flags' parameters so as to ease fu
From: Junyan He
We need to use these flags in other files rather than just in exec.c,
For example, RAM_SHARED should be used when create a ram block from file.
We expose them the exec/memory.h
Signed-off-by: Junyan He
---
exec.c| 17 -
include/exec/memory.h
From: Junyan He
QEMU writes to vNVDIMM backends in the vNVDIMM label emulation and
live migration. If the backend is on the persistent memory, QEMU needs
to take proper operations to ensure its writes persistent on the
persistent memory. Otherwise, a host power failure may result in the
loss the
: junyan...@gmx.com
Cc: qemu-devel@nongnu.org; Haozhong Zhang; xiaoguangrong.e...@gmail.com;
crosthwaite.pe...@gmail.com; m...@redhat.com; dgilb...@redhat.com;
ehabk...@redhat.com; quint...@redhat.com; Junyan He; stefa...@redhat.com;
pbonz...@redhat.com; imamm...@redhat.com; r...@twiddle.net
he hint that the flush step by step may be faster and I think the
benchmark shows that they are close.
The worst case is that all the pmem-like memory will be flushed after completing
migration, I am not sure whether there are some unused pmem for new guest will
also
be flushed.
> Dave
@gmx.com
Cc: qemu-devel@nongnu.org; Haozhong Zhang; xiaoguangrong.e...@gmail.com;
crosthwaite.pe...@gmail.com; m...@redhat.com; dgilb...@redhat.com;
ehabk...@redhat.com; quint...@redhat.com; Junyan He; stefa...@redhat.com;
pbonz...@redhat.com; imamm...@redhat.com; r...@twiddle.net
Subject: Re: [Qe
It seems that this is not caused by my patch set? And I can not duplicate in
local.
Pings, thanks
From: Qemu-devel on behalf of
Junyan He
Sent: Monday, May 21, 2018 3:19:48 AM
To: junyan...@gmx.com
Cc: Haozhong Zhang; xiaoguangrong.e...@gmail.com; cros
,
quint...@redhat.com, "Junyan He" ,
stefa...@redhat.com, pbonz...@redhat.com, imamm...@redhat.com,
r...@twiddle.net
Subject: [Qemu-devel] [PATCH V5 0/9] nvdimm: guarantee persistence of
QEMU writes to persistent memory
From: Junyan He
QEMU writes to vNVDIMM backends in the vNV
>
>
>
>
>Sent: Friday, May 11, 2018 at 5:08 AM
>From: "Murilo Opsfelder Araujo"
>To: junyan...@gmx.com
>Cc: "Haozhong Zhang" , xiaoguangrong.e...@gmail.com,
>crosthwaite.pe...@gmail.com, m...@redhat.com, qemu-devel@nongnu.org,
>dgilb...@redh
From: Junyan He
When loading a normal page to persistent memory, load its data by
libpmem function pmem_memcpy_nodrain() instead of memcpy(). Combined
with a call to pmem_drain() at the end of memory loading, we can
guarantee all those normal pages are persistenly loaded to PMEM.
Signed-off-by
From: Junyan He
Guest writes to vNVDIMM labels are intercepted and performed on the
backend by QEMU. When the backend is a real persistent memort, QEMU
needs to take proper operations to ensure its write persistence on the
persistent memory. Otherwise, a host power failure may result in the
loss
From: Junyan He
Add a pair of configure options --{enable,disable}-libpmem to control
whether QEMU is compiled with PMDK libpmem [1].
QEMU may write to the host persistent memory (e.g. in vNVDIMM label
emulation and live migration), so it must take the proper operations
to ensure the
From: Junyan He
The nvdimm kind memory does not support post copy now.
We disable post copy if we have nvdimm memory and print some
log hint to user.
Signed-off-by: Junyan He
---
migration/ram.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/migration/ram.c b/migration/ram.c
From: Junyan He
As more flag parameters besides the existing 'share' are going to be
added to following functions
memory_region_init_ram_from_file
qemu_ram_alloc_from_fd
qemu_ram_alloc_from_file
let's switch them to use the 'flags' parameters so as to ease fu
From: Junyan He
When loading a compressed page to persistent memory, flush CPU cache
after the data is decompressed. Combined with a call to pmem_drain()
at the end of memory loading, we can guarantee those compressed pages
are persistently loaded to PMEM.
Signed-off-by: Haozhong Zhang
From: Junyan He
When loading a xbzrle encoded page to persistent memory, load the data
via libpmem function pmem_memcpy_nodrain() instead of memcpy().
Combined with a call to pmem_drain() at the end of memory loading, we
can guarantee those xbzrle encoded pages are persistently loaded to PMEM
From: Junyan He
When loading a zero page, check whether it will be loaded to
persistent memory If yes, load it by libpmem function
pmem_memset_nodrain(). Combined with a call to pmem_drain() at the
end of RAM loading, we can guarantee all those zero pages are
persistently loaded.
Depending on
From: Junyan He
When QEMU emulates vNVDIMM labels and migrates vNVDIMM devices, it
needs to know whether the backend storage is a real persistent memory,
in order to decide whether special operations should be performed to
ensure the data persistence.
This boolean option 'pmem' allow
From: Junyan He
QEMU writes to vNVDIMM backends in the vNVDIMM label emulation and
live migration. If the backend is on the persistent memory, QEMU needs
to take proper operations to ensure its writes persistent on the
persistent memory. Otherwise, a host power failure may result in the
loss the
From: Junyan He
For qcow2 format, we can increase the cluster's reference count of
dependent snapshot content and link the offset to the L2 table of
the new snapshot point. This way can avoid obvious snapshot's dependent
relationship, so when we delete some snapshot point, just de
From: Junyan He
The nvdimm size is huge, sometimes is more than 256G or even more.
This is a huge burden for snapshot saving. One snapshot point with
nvdimm may occupy more than 50G disk space even with compression
enabled.
We need to introduce dependent snapshot manner to solve this problem
From: Junyan He
We need to know the section_id when we do snapshot saving.
Add a parameter to save_live_iterate function call.
Signed-off-by: Junyan He
---
hw/ppc/spapr.c | 2 +-
hw/s390x/s390-stattrib.c | 2 +-
include/migration/register.h | 2 +-
migration/block.c
From: Junyan He
We need to get the bitmap content of the snapshot when enable dirty
log trace for nvdimm.
Signed-off-by: Junyan He
---
exec.c | 7 +++
include/exec/memory.h | 9 +
include/exec/ram_addr.h | 2 ++
memory.c| 7 +++
4 files
From: Junyan He
When we save snapshot, we need qemu_file to support save dependency
operations. It should call brv_driver's save dependency functions
to implement these operations.
Signed-off-by: Junyan He
---
migration/qemu-file.c
From: Junyan He
Signed-off-by: Junyan He
---
block/snapshot.c | 45 +
include/block/snapshot.h | 7 +++
2 files changed, 52 insertions(+)
diff --git a/block/snapshot.c b/block/snapshot.c
index eacc1f1..8cc40ac 100644
--- a/block
From: Junyan He
In snapshot saving, all nvdimm kind memory will be saved in different way
and we exclude all nvdimm kind memory region in ram.c
Signed-off-by: Junyan He
---
migration/ram.c | 17 +
vl.c| 1 +
2 files changed, 18 insertions(+)
diff --git a
From: Junyan He
The nvdimm size is huge, sometimes it is more than 256G or even more.
This is a huge burden for snapshot saving. One snapshot point with
nvdimm may occupy more than 50G disk space even with compression
enabled.
We need to introduce dependent snapshot manner to solve this problem
From: Junyan He
We need to know the snapshot saving information when we do dependent
snapshot saving, e.g the name of previous snapshot. Add this global
function to query the snapshot status is usable.
Signed-off-by: Junyan He
---
include/migration/snapshot.h | 3 +++
migration/savevm.c
From: Junyan He
We need to collect dirty log for nvdimm kind memory, need to enable
memory_region_set_log for more clients rather than just VGA.
Signed-off-by: Junyan He
---
memory.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/memory.c b/memory.c
index
From: Junyan He
We want to support incremental snapshot saving, this needs the file
system support dependency saving. Later snapshots may ref the dependent
snapshot's content, and most time should be cluster aligned.
Add a query function to check whether the file system support this, and
us
From: Junyan He
We need to know the snapshot saving information when we do dependent
snapshot saving, e.g the name of previous snapshot. Add this global
function to query the snapshot status is usable.
Signed-off-by: Junyan He
---
include/migration/snapshot.h | 3 +++
migration/savevm.c
From: Junyan He
The nvdimm size is huge, sometimes is more than 256G or even more.
This is a huge burden for snapshot saving. One snapshot point with
nvdimm may occupy more than 50G disk space even with compression
enabled.
We need to introduce dependent snapshot manner to solve this problem
From: Junyan He
We need to get the bitmap content of the snapshot when enable dirty
log trace for nvdimm.
Signed-off-by: Junyan He
---
exec.c | 7 +++
include/exec/memory.h | 9 +
include/exec/ram_addr.h | 2 ++
memory.c| 7 +++
4 files
From: Junyan He
We need to know the section_id when we do snapshot saving.
Add a parameter to save_live_iterate function call.
Signed-off-by: Junyan He
---
hw/ppc/spapr.c | 2 +-
hw/s390x/s390-stattrib.c | 2 +-
include/migration/register.h | 2 +-
migration/block.c
From: Junyan He
We need to collect dirty log for nvdimm kind memory, need to enable
memory_region_set_log for more clients rather than just VGA.
Signed-off-by: Junyan He
---
memory.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/memory.c b/memory.c
index
From: Junyan He
Signed-off-by: Junyan He
---
block/snapshot.c | 45 +
include/block/snapshot.h | 7 +++
2 files changed, 52 insertions(+)
diff --git a/block/snapshot.c b/block/snapshot.c
index eacc1f1..8cc40ac 100644
--- a/block
From: Junyan He
In snapshot saving, all nvdimm kind memory will be saved in different way
and we exclude all nvdimm kind memory region in ram.c
Signed-off-by: Junyan He
---
migration/ram.c | 17 +
vl.c| 1 +
2 files changed, 18 insertions(+)
diff --git a
From: Junyan He
When we save snapshot, we need qemu_file to support save dependency
operations. It should call brv_driver's save dependency functions
to implement these operations.
Signed-off-by: Junyan He
---
migration/qemu-file.c
From: Junyan He
We want to support incremental snapshot saving, this needs the file
system support dependency saving. Later snapshots may ref the dependent
snapshot's content, and most time should be cluster aligned.
Add a query function to check whether the file system support this, and
us
From: Junyan He
For qcow2 format, we can increase the cluster's reference count of
dependent snapshot content and link the offset to the L2 table of
the new snapshot point. This way can avoid obvious snapshot's dependent
relationship, so when we delete some snapshot point, just de
From: Junyan He
The nvdimm size is huge, sometimes it is more than 256G or even more.
This is a huge burden for snapshot saving. One snapshot point with
nvdimm may occupy more than 50G disk space even with compression
enabled.
We need to introduce dependent snapshot manner to solve this problem
95 matches
Mail list logo
