From nobody Sat May 4 12:17:26 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1498679338524903.5258771471237; Wed, 28 Jun 2017 12:48:58 -0700 (PDT) Received: from localhost ([::1]:35447 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dQIxM-0008S3-RN for importer@patchew.org; Wed, 28 Jun 2017 15:48:56 -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+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 =3D rma_alloc_size; } else { spapr->rma_size =3D 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 =3D 1; spapr->rma_size =3D MIN(spapr->rma_size, 0x10000000); } This code (and the comment that precedes it) is taking constraints and cond= itions related to KVM HPT guests and filtering them with "if (kvm_enabled())". Not= e that this also means that, for KVM RADIX guests, we'll change rma_size and set t= he vrma_adjust flag as well. The flag vrma_adjust is used inside 'spapr_setup_hpt_and_vrma', which in tu= rn 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 =3D 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, lea= ving rma_size with the value MIN(spapr->rma_size, 0x10000000). This changed rma_size value is causing the code to populate more memory nod= es in 'spapr_populate_memory', which in turn results in differences in the mem= ory layout at SLOF init (alloc_top and rmo_top). At first this isn't causing bu= gs or guest misbehavior in case of KVM RADIX - the problem is that this is happen= ing 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 =3D 1; spapr->rma_size =3D 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 =3D 1; spapr->rma_size =3D MIN(spapr->rma_size, 0x10000000); } --=20 2.9.4