https://bugzilla.redhat.com/show_bug.cgi?id=1455819
Currently, the per-domain path for huge pages mmap() for qemu is
created iff domain has memoryBacking and hugepages in it
configured. However, this alone is not enough because there can
be a DIMM module with hugepages configured too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
src/qemu/qemu_process.c | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 4a66f0d5d..59cca2736 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -3283,6 +3283,31 @@ qemuProcessReconnectCheckMemAliasOrderMismatch(virDomainObjPtr vm)
}
+static bool
+qemuProcessNeedHugepagesPath(virDomainDefPtr def)
+{
+ const long system_pagesize = virGetSystemPageSizeKB();
+ size_t i;
+
+ if (def->mem.source == VIR_DOMAIN_MEMORY_SOURCE_FILE)
+ return true;
+
+ for (i = 0; i < def->mem.nhugepages; i++) {
+ if (def->mem.hugepages[i].size != system_pagesize)
+ return true;
+ }
+
+ for (i = 0; i < def->nmems; i++) {
+ if (def->mems[i]->model == VIR_DOMAIN_MEMORY_MODEL_DIMM &&
+ def->mems[i]->pagesize &&
+ def->mems[i]->pagesize != system_pagesize)
+ return true;
+ }
+
+ return false;
+}
+
+
static int
qemuProcessBuildDestroyHugepagesPath(virQEMUDriverPtr driver,
virDomainObjPtr vm,
@@ -3291,9 +3316,13 @@ qemuProcessBuildDestroyHugepagesPath(virQEMUDriverPtr driver,
virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
char *hugepagePath = NULL;
size_t i;
+ bool shouldBuild = false;
int ret = -1;
- if (vm->def->mem.nhugepages) {
+ if (build)
+ shouldBuild = qemuProcessNeedHugepagesPath(vm->def);
+
+ if (!build || shouldBuild) {
for (i = 0; i < cfg->nhugetlbfs; i++) {
VIR_FREE(hugepagePath);
hugepagePath = qemuGetDomainHugepagePath(vm->def, &cfg->hugetlbfs[i]);
--
2.13.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 06/13/2017 09:05 AM, Michal Privoznik wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1455819 > > Currently, the per-domain path for huge pages mmap() for qemu is > created iff domain has memoryBacking and hugepages in it > configured. However, this alone is not enough because there can > be a DIMM module with hugepages configured too. The reality is there can be multiple reasons, true? 1. Memory backing source file 2. Some page in the configured hugepages list that doesn't match the system pagesize 3. Some pagesize for a DIMM module that's requesting a different page size than the system page size > > Signed-off-by: Michal Privoznik <mprivozn@redhat.com> > --- > src/qemu/qemu_process.c | 31 ++++++++++++++++++++++++++++++- > 1 file changed, 30 insertions(+), 1 deletion(-) > Reviewed-by: John Ferlan <jferlan@redhat.com> John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 06/13/2017 04:14 PM, John Ferlan wrote: > > > On 06/13/2017 09:05 AM, Michal Privoznik wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=1455819 >> >> Currently, the per-domain path for huge pages mmap() for qemu is >> created iff domain has memoryBacking and hugepages in it >> configured. However, this alone is not enough because there can >> be a DIMM module with hugepages configured too. > > The reality is there can be multiple reasons, true? > > 1. Memory backing source file > 2. Some page in the configured hugepages list that doesn't match the > system pagesize > 3. Some pagesize for a DIMM module that's requesting a different page > size than the system page size True. > >> >> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> >> --- >> src/qemu/qemu_process.c | 31 ++++++++++++++++++++++++++++++- >> 1 file changed, 30 insertions(+), 1 deletion(-) >> > > Reviewed-by: John Ferlan <jferlan@redhat.com> > > John > Pushed both. Thanks, Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2025 Red Hat, Inc.