From patchwork Wed Jun 28 19:47:31 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Henrique Barboza X-Patchwork-Id: 9815273 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 30F0A60383 for ; Wed, 28 Jun 2017 19:48:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 177E427F85 for ; Wed, 28 Jun 2017 19:48:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0BAB0280CF; Wed, 28 Jun 2017 19:48:47 +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 DB85E27F85 for ; Wed, 28 Jun 2017 19:48:45 +0000 (UTC) Received: from localhost ([::1]:35445 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dQIxA-0007TF-Ar for patchwork-qemu-devel@patchwork.kernel.org; Wed, 28 Jun 2017 15:48:44 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dQIwO-0007R2-1U for qemu-devel@nongnu.org; Wed, 28 Jun 2017 15:47:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dQIwJ-0003jH-42 for qemu-devel@nongnu.org; Wed, 28 Jun 2017 15:47:56 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:35848 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dQIwI-0003ir-TV for qemu-devel@nongnu.org; Wed, 28 Jun 2017 15:47:51 -0400 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v5SJj0UG018238 for ; Wed, 28 Jun 2017 15:47:48 -0400 Received: from e24smtp01.br.ibm.com (e24smtp01.br.ibm.com [32.104.18.85]) by mx0b-001b2d01.pphosted.com with ESMTP id 2bcj0cadhm-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 28 Jun 2017 15:47:48 -0400 Received: from localhost by e24smtp01.br.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 28 Jun 2017 16:47:46 -0300 Received: from d24relay04.br.ibm.com (9.18.232.146) by e24smtp01.br.ibm.com (10.172.0.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 28 Jun 2017 16:47:43 -0300 Received: from d24av03.br.ibm.com (d24av03.br.ibm.com [9.8.31.95]) by d24relay04.br.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v5SJlhC71835312; Wed, 28 Jun 2017 16:47:43 -0300 Received: from d24av03.br.ibm.com (localhost [127.0.0.1]) by d24av03.br.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id v5SJljKx032635; Wed, 28 Jun 2017 16:47:45 -0300 Received: from localhost.localdomain ([9.85.155.25]) by d24av03.br.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id v5SJlfQ5032539; Wed, 28 Jun 2017 16:47:43 -0300 From: Daniel Henrique Barboza To: qemu-devel@nongnu.org Date: Wed, 28 Jun 2017 16:47:31 -0300 X-Mailer: git-send-email 2.9.4 X-TM-AS-MML: disable x-cbid: 17062819-1523-0000-0000-000002AFC5E9 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17062819-1524-0000-0000-00002A47FFB5 Message-Id: <20170628194731.15742-1-danielhb@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-28_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706280313 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 148.163.158.5 Subject: [Qemu-devel] [PATCH] hw/ppc/spapr.c: do not adjust rma_size with KVM RADIX in ppc_spapr_init 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-ppc@nongnu.org, mdroth@linux.vnet.ibm.com, david@gibson.dropbear.id.au Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP In ppc_spapr_init when setting rma_size we have the following verification: if (rma_alloc_size && (rma_alloc_size < node0_size)) { spapr->rma_size = rma_alloc_size; } else { spapr->rma_size = node0_size; /* With KVM, we don't actually know whether KVM supports an * unbounded RMA (PR KVM) or is limited by the hash table size * (HV KVM using VRMA), so we always assume the latter * * In that case, we also limit the initial allocations for RTAS * etc... to 256M since we have no way to know what the VRMA size * is going to be as it depends on the size of the hash table * isn't determined yet. */ if (kvm_enabled()) { spapr->vrma_adjust = 1; spapr->rma_size = MIN(spapr->rma_size, 0x10000000); } This code (and the comment that precedes it) is taking constraints and conditions related to KVM HPT guests and filtering them with "if (kvm_enabled())". Note that this also means that, for KVM RADIX guests, we'll change rma_size and set the vrma_adjust flag as well. The flag vrma_adjust is used inside 'spapr_setup_hpt_and_vrma', which in turn is called from ppc_spapr_reset as follows: if (kvm_enabled() && kvmppc_has_cap_mmu_radix()) { /* If using KVM with radix mode available, VCPUs can be started * without a HPT because KVM will start them in radix mode. * Set the GR bit in PATB so that we know there is no HPT. */ spapr->patb_entry = PATBE1_GR; } else { spapr_setup_hpt_and_vrma(spapr); } In short, when running a KVM HPT guest, rma_size is shrinked, the flag vrma_adjust is set and later on spapr_setup_hpt_and_vrma() is called to make the proper adjustments. When running a KVM RADIX guest no post adjustment is made, leaving rma_size with the value MIN(spapr->rma_size, 0x10000000). This changed rma_size value is causing the code to populate more memory nodes in 'spapr_populate_memory', which in turn results in differences in the memory layout at SLOF init (alloc_top and rmo_top). At first this isn't causing bugs or guest misbehavior in case of KVM RADIX - the problem is that this is happening due to KVM HPT code. This patch changes the if conditional inside ppc_spapr_init to: if (kvm_enabled() && !kvmppc_has_cap_mmu_radix()) { spapr->vrma_adjust = 1; spapr->rma_size = MIN(spapr->rma_size, 0x10000000); } To restrict the rma changes only to KVM HPT guests. If we need to do adjustments for RADIX we should either do it explicitly in its own code or make it clearer that a common code applies to both HPT and RADIX. Signed-off-by: Daniel Henrique Barboza --- hw/ppc/spapr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index 7d9af75..117ea9d 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -2164,7 +2164,7 @@ static void ppc_spapr_init(MachineState *machine) * is going to be as it depends on the size of the hash table * isn't determined yet. */ - if (kvm_enabled()) { + if (kvm_enabled() && !kvmppc_has_cap_mmu_radix()) { spapr->vrma_adjust = 1; spapr->rma_size = MIN(spapr->rma_size, 0x10000000); }