| Message ID | 1466585405-3769-1-git-send-email-thuth@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Jun 22, 2016 at 10:50:05AM +0200, Thomas Huth wrote: > On powerpc, we must only signal huge page support to the guest if > all memory areas are capable of supporting huge pages. The commit > 2d103aae8765 ("fix hugepage support when using memory-backend-file") > already fixed the case when the user specified the mem-path property > for NUMA memory nodes instead of using the global "-mem-path" option. > However, there is one more case where it currently can go wrong. > When specifying additional memory DIMMs without using NUMA, e.g. > > qemu-system-ppc64 -enable-kvm ... -m 1G,slots=2,maxmem=2G \ > -device pc-dimm,id=dimm-mem1,memdev=mem1 -object \ > memory-backend-file,policy=default,mem-path=/...,size=1G,id=mem1 > > the code in getrampagesize() currently assumes that huge pages > are possible since they are enabled for the mem1 object. But > since the main RAM is not backed by a huge page filesystem, > the guest Linux kernel then crashes very quickly after being > started. So in case the we've got "normal" memory without NUMA > and without the global "-mem-path" option, we must not announce > huge pages to the guest. Since this is likely a mis-configuration > by the user, also spill out a message in this case. > > Signed-off-by: Thomas Huth <thuth@redhat.com> Applied to ppc-for-2.7.
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c index e14da60..884d564 100644 --- a/target-ppc/kvm.c +++ b/target-ppc/kvm.c @@ -27,6 +27,7 @@ #include "qemu/timer.h" #include "sysemu/sysemu.h" #include "sysemu/kvm.h" +#include "sysemu/numa.h" #include "kvm_ppc.h" #include "sysemu/cpus.h" #include "sysemu/device_tree.h" @@ -388,7 +389,21 @@ static long getrampagesize(void) object_child_foreach(memdev_root, find_max_supported_pagesize, &hpsize); - return (hpsize == LONG_MAX) ? getpagesize() : hpsize; + if (hpsize == LONG_MAX) { + return getpagesize(); + } + + if (nb_numa_nodes == 0 && hpsize > getpagesize()) { + /* No NUMA nodes and normal RAM without -mem-path ==> no huge pages! */ + static bool warned; + if (!warned) { + error_report("Huge page support disabled (n/a for main memory)."); + warned = true; + } + return getpagesize(); + } + + return hpsize; } static bool kvm_valid_page_size(uint32_t flags, long rampgsize, uint32_t shift)
On powerpc, we must only signal huge page support to the guest if all memory areas are capable of supporting huge pages. The commit 2d103aae8765 ("fix hugepage support when using memory-backend-file") already fixed the case when the user specified the mem-path property for NUMA memory nodes instead of using the global "-mem-path" option. However, there is one more case where it currently can go wrong. When specifying additional memory DIMMs without using NUMA, e.g. qemu-system-ppc64 -enable-kvm ... -m 1G,slots=2,maxmem=2G \ -device pc-dimm,id=dimm-mem1,memdev=mem1 -object \ memory-backend-file,policy=default,mem-path=/...,size=1G,id=mem1 the code in getrampagesize() currently assumes that huge pages are possible since they are enabled for the mem1 object. But since the main RAM is not backed by a huge page filesystem, the guest Linux kernel then crashes very quickly after being started. So in case the we've got "normal" memory without NUMA and without the global "-mem-path" option, we must not announce huge pages to the guest. Since this is likely a mis-configuration by the user, also spill out a message in this case. Signed-off-by: Thomas Huth <thuth@redhat.com> --- target-ppc/kvm.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)