Ideally, we would have the security driver relabelling the paths qemu is going
to touch. And this indeed is how I approached this problem firstly. But there
are couple of problems:

a) we generate the paths, add them onto the cmd line and forget them. You won't
find them in virDomainDef. The secdriver cannot reconstruct them either as they
may depend on qemu.conf (admin can whitelist just a few hugetlbfs mount points).

b) Storing the paths in virDomainDef (which is all the the secriver sees) turns
out to be not trivial too: where would you store them? In function that
constructs the paths (qemuBuildMemoryBackendStr) we don't know what 'device'
are we working with. All the callers either pass memory dev directly (for
<memory/> cells), or construct a dummy one (for <memoryBacking/> and <numa/>
cells) and pass it. This we wouldn't know where to store the constructed path
anyway.


This solution presented here turned out to be the least painful (yet not very
clear from design POV, I give you that).

Michal Privoznik (2):
  qemuProcessBuildDestroyHugepagesPath: create path more frequently
  qemuDomainAttachMemory: Crate hugepage dir if needed

 src/qemu/qemu_hotplug.c |  3 +++
 src/qemu/qemu_process.c | 44 +++++++++++++++++++++++++++++++++++++++-----
 src/qemu/qemu_process.h |  5 +++++
 3 files changed, 47 insertions(+), 5 deletions(-)

-- 
2.13.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list