On 04/17/2018 10:05 AM, Peter Krempa wrote:
On Thu, Apr 12, 2018 at 18:39:52 +0200, Michal Privoznik wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1480668
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- src/qemu/qemu_command.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index f864350bd5..67350719aa 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -3148,6 +3148,12 @@ qemuBuildMemoryBackendStr(virJSONValuePtr *backendProps, NULL) < 0) goto cleanup;
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD) && + virJSONValueObjectAdd(props, + "B:discard-data", true,
This code path is used also for NVDIMMs, and since the documentaion for the option states that:
The new option can be used to indicate that the file contents can be destroyed and don't need to be flushed to disk when QEMU exits or when the memory backend object is removed.
I'm not sure whether this is right.
Okay, I'll make it configurable via domain XML. However, I'm struggling to come up with useful design. Perhaps we can have <discardData/> element under <memoryBacking/>? <memoryBacking> <discardData/> </memoryBacking> and in order to be able to fine tune this per nvdimm/RAM modules we can have: <memory model='nvdimm'> <source ../> <target ../> <discardData/> </memory> However, this would allow the element even for cases when memory-backing-ram is used (or the old way of configuration without any memory-backend-* at all). Michal