]> git.ipfire.org Git - thirdparty/libvirt.git/commit
qemuProcessReconnect: Don't build memory paths v8.8.0-rc2
authorMichal Privoznik <mprivozn@redhat.com>
Wed, 28 Sep 2022 08:12:36 +0000 (10:12 +0200)
committerMichal Privoznik <mprivozn@redhat.com>
Fri, 30 Sep 2022 08:09:42 +0000 (10:09 +0200)
commit3478cca80ea7382cfdbff836d5d0b92aa014297b
treea8e3e1abd1bcfd7361f82c044e7452c888c3b247
parent135233df268ed2a4f1c987039c7c843a347dc52b
qemuProcessReconnect: Don't build memory paths

Let me take you on a short trip to history. A long time ago,
libvirt would configure all QEMUs to use $hugetlbfs/libvirt/qemu
for their hugepages setup. This was problematic, because it did
not allow enough separation between guests. Therefore in
v3.0.0-rc1~367 the path changed to a per-domain basis:

  $hugetlbfs/libvirt/qemu/$domainShortName

And to help with migration on daemon restart a call to
qemuProcessBuildDestroyMemoryPaths() was added to
qemuProcessReconnect() (well, it was named
qemuProcessBuildDestroyHugepagesPath() back then, see
v3.10.0-rc1~174). This was desirable then, because the memory
hotplug code did not call the function, it simply assumes
per-domain paths to exist. But this changed in v3.5.0-rc1~92
after which the per-domain paths are created on memory hotplug
too.

Therefore, it's no longer necessary to create these paths in
qemuProcessReconnect(). They are created exactly when needed
(domain startup and memory hotplug).

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
src/qemu/qemu_process.c