From patchwork Wed Jun 22 08:50:05 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Huth X-Patchwork-Id: 9192189 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1556B6075C for ; Wed, 22 Jun 2016 08:50:40 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 025411FFB9 for ; Wed, 22 Jun 2016 08:50:40 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EB7D9283E9; Wed, 22 Jun 2016 08:50:39 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 96D201FFB9 for ; Wed, 22 Jun 2016 08:50:39 +0000 (UTC) Received: from localhost ([::1]:56615 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFdrp-0004hR-9r for patchwork-qemu-devel@patchwork.kernel.org; Wed, 22 Jun 2016 04:50:37 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48021) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFdrS-0004ey-2W for qemu-devel@nongnu.org; Wed, 22 Jun 2016 04:50:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFdrN-0001YL-Tl for qemu-devel@nongnu.org; Wed, 22 Jun 2016 04:50:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFdrN-0001XW-OY; Wed, 22 Jun 2016 04:50:09 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 192AC8E251; Wed, 22 Jun 2016 08:50:08 +0000 (UTC) Received: from thh440s.redhat.com (ovpn-116-29.ams2.redhat.com [10.36.116.29]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5M8o5eS014746; Wed, 22 Jun 2016 04:50:06 -0400 From: Thomas Huth To: qemu-ppc@nongnu.org, david@gibson.dropbear.id.au, Michael Roth Date: Wed, 22 Jun 2016 10:50:05 +0200 Message-Id: <1466585405-3769-1-git-send-email-thuth@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 22 Jun 2016 08:50:08 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH] ppc: Disable huge page support if it is not available for main RAM X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: qemu-devel@nongnu.org, Alexander Graf Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP 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 --- target-ppc/kvm.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) 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)