From patchwork Fri Mar 29 03:29:29 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Gibson X-Patchwork-Id: 10876325 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id A1BB615AC for ; Fri, 29 Mar 2019 03:34:24 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8BA4D28893 for ; Fri, 29 Mar 2019 03:34:24 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7FFF628906; Fri, 29 Mar 2019 03:34:24 +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=-2.7 required=2.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 2801528893 for ; Fri, 29 Mar 2019 03:34:24 +0000 (UTC) Received: from localhost ([127.0.0.1]:45584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h9iHf-0003PH-Ep for patchwork-qemu-devel@patchwork.kernel.org; Thu, 28 Mar 2019 23:34:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50777) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h9iD8-00080C-Br for qemu-devel@nongnu.org; Thu, 28 Mar 2019 23:29:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h9iD7-0008Ce-5h for qemu-devel@nongnu.org; Thu, 28 Mar 2019 23:29:42 -0400 Received: from ozlabs.org ([203.11.71.1]:53565) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h9iD6-0008BO-LK; Thu, 28 Mar 2019 23:29:41 -0400 Received: by ozlabs.org (Postfix, from userid 1007) id 44VnKV1XgCz9sR7; Fri, 29 Mar 2019 14:29:33 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1553830174; bh=uXhG/9dBHCOynv+dn/9p3kL3JHQy7lMtlft++onejr8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GT7sL9wRHDB/urEutGGmO079YXTVyt0/NeNU0AwU/o8jgo47pX97RwLwlWP41NWkA YCwFBSBjjaH7frvrr/JXYxDj7WynJ9tqxGKsLN+k0FDn8H1dlML/acDgQG0kmuElq8 e05v/w9+MkBTWo616bTBrlSA/b6a/oNf0lRRT6+w= From: David Gibson To: peter.maydell@linaro.org Date: Fri, 29 Mar 2019 14:29:29 +1100 Message-Id: <20190329032929.21072-9-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190329032929.21072-1-david@gibson.dropbear.id.au> References: <20190329032929.21072-1-david@gibson.dropbear.id.au> MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 203.11.71.1 Subject: [Qemu-devel] [PULL 8/8] exec: Only count mapped memory backends for qemu_getrampagesize() 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: david@redhat.com, qemu-devel@nongnu.org, groug@kaod.org, qemu-ppc@nongnu.org, imammedo@redhat.com, David Gibson Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP qemu_getrampagesize() works out the minimum host page size backing any of guest RAM. This is required in a few places, such as for POWER8 PAPR KVM guests, because limitations of the hardware virtualization mean the guest can't use pagesizes larger than the host pages backing its memory. However, it currently checks against *every* memory backend, whether or not it is actually mapped into guest memory at the moment. This is incorrect. This can cause a problem attempting to add memory to a POWER8 pseries KVM guest which is configured to allow hugepages in the guest (e.g. -machine cap-hpt-max-page-size=16m). If you attempt to add non-hugepage, you can (correctly) create a memory backend, however it (correctly) will throw an error when you attempt to map that memory into the guest by 'device_add'ing a pc-dimm. What's not correct is that if you then reset the guest a startup check against qemu_getrampagesize() will cause a fatal error because of the new memory object, even though it's not mapped into the guest. This patch corrects the problem by adjusting find_max_supported_pagesize() (called from qemu_getrampagesize() via object_child_foreach) to exclude non-mapped memory backends. Signed-off-by: David Gibson Reviewed-by: Igor Mammedov Acked-by: David Hildenbrand --- exec.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/exec.c b/exec.c index 86a38d3b3b..6ab62f4eee 100644 --- a/exec.c +++ b/exec.c @@ -1692,9 +1692,10 @@ static int find_max_supported_pagesize(Object *obj, void *opaque) long *hpsize_min = opaque; if (object_dynamic_cast(obj, TYPE_MEMORY_BACKEND)) { - long hpsize = host_memory_backend_pagesize(MEMORY_BACKEND(obj)); + HostMemoryBackend *backend = MEMORY_BACKEND(obj); + long hpsize = host_memory_backend_pagesize(backend); - if (hpsize < *hpsize_min) { + if (host_memory_backend_is_mapped(backend) && (hpsize < *hpsize_min)) { *hpsize_min = hpsize; } }