[libvirt] [PATCH] qemuBuildMemPathStr: Produce -mem-path more frequently

John Ferlan jferlan at redhat.com
Wed Sep 5 19:28:12 UTC 2018



On 08/30/2018 08:01 AM, Michal Privoznik wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1622455
> 
> If a domain is configured to use <source type='file'/> under
> <memoryBacking/> we have to honour that setting and produce
> -mem-path on the command line. We are not doing so if domain has
> no guest NUMA nodes nor hugepages.
> 
> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> ---
>  src/qemu/qemu_command.c                            | 29 +++++++++++-----------
>  .../fd-memory-no-numa-topology.args                |  1 +
>  2 files changed, 16 insertions(+), 14 deletions(-)
> 

The code and result look right and a domain can boot like this, so

Reviewed-by: John Ferlan <jferlan at redhat.com>

John

Still, looking at the original commit series it's not exactly "clear"
whether numa mattered or not...

Commit 0857a3bf5 (news.xml) notes "Add support in numa topology...", but
commit bc6d3121a (formatdomain.html.in) doesn't mention numa. It's too
bad the added <source> wasn't a bit more detailed and let's face it the
<allocation> is seriously lacking any substance. I wonder if <source>
should also mention hypervisor specific, yadda, yadda, but more
importantly the qemu memory_backing_dir "link" so that people understand
for qemu where things get created.  I also note that for my 2G guest
there was a *definite* pause when just adding the <memoryBacking>
<source type='file'/> </memoryBacking> when starting up...

In any case, hopefully you can post a followup for formatdomain
'details' - it doesn't have to be part of the bz unless you believe
doing so is "that important" (so to speak).




More information about the libvir-list mailing list