From patchwork Mon Mar 4 10:13:39 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Auger X-Patchwork-Id: 10837561 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 19C091390 for ; Mon, 4 Mar 2019 10:23:10 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0714E2996E for ; Mon, 4 Mar 2019 10:23:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EC5C329989; Mon, 4 Mar 2019 10:23:09 +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.9 required=2.0 tests=BAYES_00,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 78A0F2993E for ; Mon, 4 Mar 2019 10:23:09 +0000 (UTC) Received: from localhost ([127.0.0.1]:51464 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h0kkW-0000Gn-NU for patchwork-qemu-devel@patchwork.kernel.org; Mon, 04 Mar 2019 05:23:08 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h0kdG-0002dN-JV for qemu-devel@nongnu.org; Mon, 04 Mar 2019 05:15:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h0kdF-0001HC-Lm for qemu-devel@nongnu.org; Mon, 04 Mar 2019 05:15:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54774) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h0kdC-0001Em-Nz; Mon, 04 Mar 2019 05:15:35 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C9037308425A; Mon, 4 Mar 2019 10:15:33 +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 8CD455C2EC; Mon, 4 Mar 2019 10:15:13 +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: Mon, 4 Mar 2019 11:13:39 +0100 Message-Id: <20190304101339.25970-11-eric.auger@redhat.com> In-Reply-To: <20190304101339.25970-1-eric.auger@redhat.com> References: <20190304101339.25970-1-eric.auger@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Mon, 04 Mar 2019 10:15:33 +0000 (UTC) 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 v12 10/10] 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+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP 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 Reviewed-by: Igor Mammedov --- v11 -> v12: - Added Igor's R-b 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 d725daefdf..c7fb5348ae 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -95,20 +95,7 @@ #define PLATFORM_BUS_NUM_IRQS 64 -/* 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 spaces - * (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.) - */ +/* Legacy RAM limit in GB (< version 4.0) */ #define LEGACY_RAMLIMIT_GB 255 #define LEGACY_RAMLIMIT_BYTES (LEGACY_RAMLIMIT_GB * GiB) @@ -1516,12 +1503,6 @@ static void machvirt_init(MachineState *machine) vms->smp_cpus = smp_cpus; - 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");