[Qemu-devel] [PATCH] target-ppc: fix hugepage support when using memory-backend-file

[Qemu-devel] [PATCH] target-ppc: fix hugepage support when using memory-backend-file

[Michael Roth]

Current PPC code relies on -mem-path being used in order for
hugepage support to be detected. With the introduction of
MemoryBackendFile we can now handle this via:
  -object memory-file-backend,mem-path=...,id=hugemem0 \
  -numa node,id=mem0,memdev=hugemem0

Management tools like libvirt treat the 2 approaches as
interchangeable in some cases, which can lead to user-visible
regressions even for previously supported guest configurations.

Fix these by also iterating through any configured memory
backends that may be backed by hugepages.

Since the old code assumed hugepages always backed the entirety
of guest memory, play it safe an pick the minimum across the
max pages sizes for all backends, even ones that aren't backed
by hugepages.

Cc: qemu-stable@nongnu.org
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
---
 target-ppc/kvm.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 51 insertions(+), 6 deletions(-)

diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index afb4696..5db2045 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -40,6 +40,7 @@
 #include "trace.h"
 #include "exec/gdbstub.h"
 #include "exec/memattrs.h"
+#include "sysemu/hostmem.h"
 
 //#define DEBUG_KVM
 
@@ -303,16 +304,11 @@ static void kvm_get_smmu_info(PowerPCCPU *cpu, struct kvm_ppc_smmu_info *info)
     kvm_get_fallback_smmu_info(cpu, info);
 }
 
-static long getrampagesize(void)
+static long gethugepagesize(const char *mem_path)
 {
     struct statfs fs;
     int ret;
 
-    if (!mem_path) {
-        /* guest RAM is backed by normal anonymous pages */
-        return getpagesize();
-    }
-
     do {
         ret = statfs(mem_path, &fs);
     } while (ret != 0 && errno == EINTR);
@@ -334,6 +330,55 @@ static long getrampagesize(void)
     return fs.f_bsize;
 }
 
+static int find_max_supported_pagesize(Object *obj, void *opaque)
+{
+    char *mem_path;
+    long *hpsize_min = opaque;
+
+    if (object_dynamic_cast(obj, TYPE_MEMORY_BACKEND)) {
+        mem_path = object_property_get_str(obj, "mem-path", NULL);
+        if (mem_path) {
+            long hpsize = gethugepagesize(mem_path);
+            if (hpsize < *hpsize_min) {
+                *hpsize_min = hpsize;
+            }
+        } else {
+            *hpsize_min = getpagesize();
+        }
+    }
+
+    return 0;
+}
+
+static long getrampagesize(void)
+{
+    long hpsize = LONG_MAX;
+    Object *memdev_root;
+
+    if (mem_path) {
+        return gethugepagesize(mem_path);
+    }
+
+    /* it's possible we have memory-backend objects with
+     * hugepage-backed RAM. these may get mapped into system
+     * address space via -numa parameters or memory hotplug
+     * hooks. we want to take these into account, but we
+     * also want to make sure these supported hugepage
+     * sizes are applicable across the entire range of memory
+     * we may boot from, so we take the min across all
+     * backends, and assume normal pages in cases where a
+     * backend isn't backed by hugepages.
+     */
+    memdev_root = object_resolve_path("/objects", NULL);
+    if (!memdev_root) {
+        return getpagesize();
+    }
+
+    object_child_foreach(memdev_root, find_max_supported_pagesize, &hpsize);
+
+    return (hpsize == LONG_MAX) ? getpagesize() : hpsize;
+}
+
 static bool kvm_valid_page_size(uint32_t flags, long rampgsize, uint32_t shift)
 {
     if (!(flags & KVM_PPC_PAGE_SIZES_REAL)) {
-- 
1.9.1

Re: [Qemu-devel] [PATCH] target-ppc: fix hugepage support when using memory-backend-file

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]

On Thu, Jul 02, 2015 at 03:46:14PM -0500, Michael Roth wrote:
> Current PPC code relies on -mem-path being used in order for
> hugepage support to be detected. With the introduction of
> MemoryBackendFile we can now handle this via:
>   -object memory-file-backend,mem-path=...,id=hugemem0 \
>   -numa node,id=mem0,memdev=hugemem0
> 
> Management tools like libvirt treat the 2 approaches as
> interchangeable in some cases, which can lead to user-visible
> regressions even for previously supported guest configurations.
> 
> Fix these by also iterating through any configured memory
> backends that may be backed by hugepages.
> 
> Since the old code assumed hugepages always backed the entirety
> of guest memory, play it safe an pick the minimum across the
> max pages sizes for all backends, even ones that aren't backed
> by hugepages.
> 
> Cc: qemu-stable@nongnu.org
> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] [PATCH] target-ppc: fix hugepage support when using memory-backend-file

[Alexander Graf]

On 07/03/15 09:18, David Gibson wrote:
> On Thu, Jul 02, 2015 at 03:46:14PM -0500, Michael Roth wrote:
>> Current PPC code relies on -mem-path being used in order for
>> hugepage support to be detected. With the introduction of
>> MemoryBackendFile we can now handle this via:
>>    -object memory-file-backend,mem-path=...,id=hugemem0 \
>>    -numa node,id=mem0,memdev=hugemem0
>>
>> Management tools like libvirt treat the 2 approaches as
>> interchangeable in some cases, which can lead to user-visible
>> regressions even for previously supported guest configurations.
>>
>> Fix these by also iterating through any configured memory
>> backends that may be backed by hugepages.
>>
>> Since the old code assumed hugepages always backed the entirety
>> of guest memory, play it safe an pick the minimum across the
>> max pages sizes for all backends, even ones that aren't backed
>> by hugepages.
>>
>> Cc: qemu-stable@nongnu.org
>> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
>

Thanks, applied to ppc-next.


Alex

Re: [Qemu-devel] [PATCH] target-ppc: fix hugepage support when using memory-backend-file

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1523 bytes --]

On Mon, Jul 06, 2015 at 10:53:47AM +0200, Alexander Graf wrote:
> On 07/03/15 09:18, David Gibson wrote:
> >On Thu, Jul 02, 2015 at 03:46:14PM -0500, Michael Roth wrote:
> >>Current PPC code relies on -mem-path being used in order for
> >>hugepage support to be detected. With the introduction of
> >>MemoryBackendFile we can now handle this via:
> >>   -object memory-file-backend,mem-path=...,id=hugemem0 \
> >>   -numa node,id=mem0,memdev=hugemem0
> >>
> >>Management tools like libvirt treat the 2 approaches as
> >>interchangeable in some cases, which can lead to user-visible
> >>regressions even for previously supported guest configurations.
> >>
> >>Fix these by also iterating through any configured memory
> >>backends that may be backed by hugepages.
> >>
> >>Since the old code assumed hugepages always backed the entirety
> >>of guest memory, play it safe an pick the minimum across the
> >>max pages sizes for all backends, even ones that aren't backed
> >>by hugepages.
> >>
> >>Cc: qemu-stable@nongnu.org
> >>Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
> >Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> >
> 
> Thanks, applied to ppc-next.

Hrm.. I see that you've pushed out ppc-next with this patch, but looks
like it hasn't been rebased on latest master.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] [PATCH] target-ppc: fix hugepage support when using memory-backend-file

[Alexander Graf]

On 07/06/15 13:09, David Gibson wrote:
> On Mon, Jul 06, 2015 at 10:53:47AM +0200, Alexander Graf wrote:
>> On 07/03/15 09:18, David Gibson wrote:
>>> On Thu, Jul 02, 2015 at 03:46:14PM -0500, Michael Roth wrote:
>>>> Current PPC code relies on -mem-path being used in order for
>>>> hugepage support to be detected. With the introduction of
>>>> MemoryBackendFile we can now handle this via:
>>>>    -object memory-file-backend,mem-path=...,id=hugemem0 \
>>>>    -numa node,id=mem0,memdev=hugemem0
>>>>
>>>> Management tools like libvirt treat the 2 approaches as
>>>> interchangeable in some cases, which can lead to user-visible
>>>> regressions even for previously supported guest configurations.
>>>>
>>>> Fix these by also iterating through any configured memory
>>>> backends that may be backed by hugepages.
>>>>
>>>> Since the old code assumed hugepages always backed the entirety
>>>> of guest memory, play it safe an pick the minimum across the
>>>> max pages sizes for all backends, even ones that aren't backed
>>>> by hugepages.
>>>>
>>>> Cc: qemu-stable@nongnu.org
>>>> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
>>> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
>>>
>> Thanks, applied to ppc-next.
> Hrm.. I see that you've pushed out ppc-next with this patch, but looks
> like it hasn't been rebased on latest master.

Yup. Done now.


Alex