From nobody Sun Nov 9 17:52:11 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (209.51.188.17 [209.51.188.17]) by mx.zohomail.com with SMTPS id 1551189550232950.4202707916044; Tue, 26 Feb 2019 05:59:10 -0800 (PST) Received: from localhost ([127.0.0.1]:55714 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gydGC-0006HD-3q for importer@patchew.org; Tue, 26 Feb 2019 08:59:04 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gyd8g-0000LS-Ur for qemu-devel@nongnu.org; Tue, 26 Feb 2019 08:51:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gyd8g-0007Gn-2o for qemu-devel@nongnu.org; Tue, 26 Feb 2019 08:51:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55250) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gyd8d-0007E2-Uh; Tue, 26 Feb 2019 08:51:16 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3A14530044F6; Tue, 26 Feb 2019 13:51:15 +0000 (UTC) Received: from laptop.redhat.com (ovpn-116-102.ams2.redhat.com [10.36.116.102]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7F6D35F726; Tue, 26 Feb 2019 13:51:12 +0000 (UTC) From: Eric Auger To: eric.auger.pro@gmail.com, eric.auger@redhat.com, qemu-devel@nongnu.org, qemu-arm@nongnu.org, peter.maydell@linaro.org, shameerali.kolothum.thodi@huawei.com, imammedo@redhat.com, david@redhat.com Date: Tue, 26 Feb 2019 14:50:06 +0100 Message-Id: <20190226135014.31854-11-eric.auger@redhat.com> In-Reply-To: <20190226135014.31854-1-eric.auger@redhat.com> References: <20190226135014.31854-1-eric.auger@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Tue, 26 Feb 2019 13:51:15 +0000 (UTC) Content-Transfer-Encoding: quoted-printable 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 v8 10/18] hw/arm/virt: Bump the 255GB initial RAM limit 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: pbonzini@redhat.com, drjones@redhat.com, dgilbert@redhat.com, david@gibson.dropbear.id.au Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" Now we have the extended memory map (high IO regions beyond the scalable RAM) and dynamic IPA range support at KVM/ARM level we can bump the legacy 255GB initial RAM limit. The actual maximum RAM size now depends on the physical CPU and host kernel, in accelerated mode. In TCG mode, it depends on the VCPU AA64MMFR0.PARANGE. Signed-off-by: Eric Auger --- v7 -> v8: - TCG PAMAX check moved in a separate patch v6 -> v7 - handle TCG case - set_memmap modifications moved to previous patches --- hw/arm/virt.c | 21 +-------------------- 1 file changed, 1 insertion(+), 20 deletions(-) diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 17a34574ae..aa77b54beb 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -95,21 +95,8 @@ =20 #define PLATFORM_BUS_NUM_IRQS 64 =20 -/* RAM limit in GB. Since VIRT_MEM starts at the 1GB mark, this means - * RAM can go up to the 256GB mark, leaving 256GB of the physical - * address space unallocated and free for future use between 256G and 512G. - * If we need to provide more RAM to VMs in the future then we need to: - * * allocate a second bank of RAM starting at 2TB and working up - * * fix the DT and ACPI table generation code in QEMU to correctly - * report two split lumps of RAM to the guest - * * fix KVM in the host kernel to allow guests with >40 bit address spac= es - * (We don't want to fill all the way up to 512GB with RAM because - * we might want it for non-RAM purposes later. Conversely it seems - * reasonable to assume that anybody configuring a VM with a quarter - * of a terabyte of RAM will be doing it on a host with more than a - * terabyte of physical address space.) - */ #define RAMBASE GiB +/* Legacy RAM limit in GB (< version 4.0) */ #define LEGACY_RAMLIMIT_GB 255 #define LEGACY_RAMLIMIT_BYTES (LEGACY_RAMLIMIT_GB * GiB) =20 @@ -1511,12 +1498,6 @@ static void machvirt_init(MachineState *machine) =20 vms->smp_cpus =3D smp_cpus; =20 - if (machine->ram_size > vms->memmap[VIRT_MEM].size) { - error_report("mach-virt: cannot model more than %dGB RAM", - LEGACY_RAMLIMIT_GB); - exit(1); - } - if (vms->virt && kvm_enabled()) { error_report("mach-virt: KVM does not support providing " "Virtualization extensions to the guest CPU"); --=20 2.20.1