From patchwork Tue Mar 26 03:50:58 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Gibson X-Patchwork-Id: 1065103 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.b="g1HDXWT7"; dkim-atps=neutral Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 44Sy3118pgz9sSS for ; Tue, 26 Mar 2019 14:55:41 +1100 (AEDT) Received: from localhost ([127.0.0.1]:52177 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h8dBb-0008Gj-2D for incoming@patchwork.ozlabs.org; Mon, 25 Mar 2019 23:55:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38328) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h8dAc-0007o5-AM for qemu-devel@nongnu.org; Mon, 25 Mar 2019 23:54:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h8d9O-0001A0-Pb for qemu-devel@nongnu.org; Mon, 25 Mar 2019 23:53:24 -0400 Received: from ozlabs.org ([203.11.71.1]:54851) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h8d9L-00018i-BY; Mon, 25 Mar 2019 23:53:21 -0400 Received: by ozlabs.org (Postfix, from userid 1007) id 44Sy086ZNYz9sSg; Tue, 26 Mar 2019 14:53:12 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1553572392; bh=SseERvyJCcDi64IlI8MZn8+urA0v5ZKvZkP/kAAUQUs=; h=From:To:Cc:Subject:Date:From; b=g1HDXWT73kQSkXcU5gtrDxbCbP8d/TClMEQ6hmmLHrQ1bljf1l/DSOHJPk9Jh6YKE ZNqsCpy2P4qgKLRXTFasT9sH6MfW2k0YfdJ7yYlLBjxph88hta3vRz5uahkeL6eIFT FxgbQA6ZUty2q45Iz8OG0rcJaYLXKm2HCjUqPwAY= From: David Gibson To: pbonzini@redhat.com, rth@twiddle.net, peter.maydell@linaro.org, imammedo@redhat.com Date: Tue, 26 Mar 2019 14:50:58 +1100 Message-Id: <20190326035058.20634-1-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.20.1 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] [PATCH for-4.0?] 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: aik@ozlabs.ru, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, David Gibson Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" 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: Laurent Vivier Reviewed-by: Igor Mammedov Acked-by: David Hildenbrand --- exec.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) This is definitely a bug, but it's not a regression. I'm not sure if this is 4.0 material at this stage of the freeze or not. 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; } }