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(a)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