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