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@xxxxxxxxxx> > --- > 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@xxxxxxxxxx> 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). -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
