From: Igor Mammedov <imammedo@redhat.com>
To: Eric Auger <eric.auger@redhat.com>
Cc: peter.maydell@linaro.org, drjones@redhat.com, david@redhat.com,
qemu-devel@nongnu.org, shameerali.kolothum.thodi@huawei.com,
dgilbert@redhat.com, qemu-arm@nongnu.org, pbonzini@redhat.com,
david@gibson.dropbear.id.au, eric.auger.pro@gmail.com
Subject: Re: [Qemu-arm] [PATCH v10 10/10] hw/arm/virt: Bump the 255GB initial RAM limit
Date: Thu, 28 Feb 2019 17:29:38 +0100 [thread overview]
Message-ID: <20190228172938.1993ed57@redhat.com> (raw)
In-Reply-To: <20190228150324.25973-11-eric.auger@redhat.com>
On Thu, 28 Feb 2019 16:03:24 +0100
Eric Auger <eric.auger@redhat.com> wrote:
> 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 <eric.auger@redhat.com>
>
> ---
> 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 a3da75a5ae..a45f0fcf79 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -95,21 +95,8 @@
>
> #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.)
> - */
> #define RAMBASE GiB
> +/* Legacy RAM limit in GB (< version 4.0) */
> #define LEGACY_RAMLIMIT_GB 255
> #define LEGACY_RAMLIMIT_BYTES (LEGACY_RAMLIMIT_GB * GiB)
do we need to keep these couple around?
it's used only in
[VIRT_MEM] = { RAMBASE, LEGACY_RAMLIMIT_BYTES },
and doesn't have any effect whatsoever.
I'd set initial VIRT_MEM.size to 0 and drop LEGACY_RAMLIMIT_*
maybe add comment above entry that size is defined by ram_size
>
> @@ -1515,12 +1502,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");
WARNING: multiple messages have this Message-ID (diff)
From: Igor Mammedov <imammedo@redhat.com>
To: Eric Auger <eric.auger@redhat.com>
Cc: eric.auger.pro@gmail.com, qemu-devel@nongnu.org,
qemu-arm@nongnu.org, peter.maydell@linaro.org,
shameerali.kolothum.thodi@huawei.com, david@redhat.com,
dgilbert@redhat.com, david@gibson.dropbear.id.au,
drjones@redhat.com, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH v10 10/10] hw/arm/virt: Bump the 255GB initial RAM limit
Date: Thu, 28 Feb 2019 17:29:38 +0100 [thread overview]
Message-ID: <20190228172938.1993ed57@redhat.com> (raw)
In-Reply-To: <20190228150324.25973-11-eric.auger@redhat.com>
On Thu, 28 Feb 2019 16:03:24 +0100
Eric Auger <eric.auger@redhat.com> wrote:
> 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 <eric.auger@redhat.com>
>
> ---
> 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 a3da75a5ae..a45f0fcf79 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -95,21 +95,8 @@
>
> #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.)
> - */
> #define RAMBASE GiB
> +/* Legacy RAM limit in GB (< version 4.0) */
> #define LEGACY_RAMLIMIT_GB 255
> #define LEGACY_RAMLIMIT_BYTES (LEGACY_RAMLIMIT_GB * GiB)
do we need to keep these couple around?
it's used only in
[VIRT_MEM] = { RAMBASE, LEGACY_RAMLIMIT_BYTES },
and doesn't have any effect whatsoever.
I'd set initial VIRT_MEM.size to 0 and drop LEGACY_RAMLIMIT_*
maybe add comment above entry that size is defined by ram_size
>
> @@ -1515,12 +1502,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");
next prev parent reply other threads:[~2019-02-28 16:30 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-28 15:03 [Qemu-arm] [PATCH v10 00/10] ARM virt: Initial RAM expansion and extended memory map Eric Auger
2019-02-28 15:03 ` [Qemu-devel] " Eric Auger
2019-02-28 15:03 ` [Qemu-arm] [PATCH v10 01/10] hw/arm/boot: introduce fdt_add_memory_node helper Eric Auger
2019-02-28 15:03 ` [Qemu-devel] " Eric Auger
2019-02-28 15:03 ` [Qemu-arm] [PATCH v10 02/10] hw/arm/virt: Rename highmem IO regions Eric Auger
2019-02-28 15:03 ` [Qemu-devel] " Eric Auger
2019-02-28 15:03 ` [Qemu-arm] [PATCH v10 03/10] hw/arm/virt: Split the memory map description Eric Auger
2019-02-28 15:03 ` [Qemu-devel] " Eric Auger
2019-02-28 15:51 ` [Qemu-arm] " Igor Mammedov
2019-02-28 15:51 ` [Qemu-devel] " Igor Mammedov
2019-02-28 15:03 ` [Qemu-devel] [PATCH v10 04/10] hw/boards: Add a MachineState parameter to kvm_type callback Eric Auger
2019-02-28 15:03 ` Eric Auger
2019-02-28 15:03 ` [Qemu-arm] [PATCH v10 05/10] kvm: add kvm_arm_get_max_vm_ipa_size Eric Auger
2019-02-28 15:03 ` [Qemu-devel] " Eric Auger
2019-02-28 16:02 ` [Qemu-arm] " Igor Mammedov
2019-02-28 16:02 ` [Qemu-devel] " Igor Mammedov
2019-02-28 15:03 ` [Qemu-arm] [PATCH v10 06/10] vl: Set machine ram_size, maxram_size and ram_slots earlier Eric Auger
2019-02-28 15:03 ` [Qemu-devel] " Eric Auger
2019-02-28 15:03 ` [Qemu-devel] [PATCH v10 07/10] hw/arm/virt: Dynamic memory map depending on RAM requirements Eric Auger
2019-02-28 15:03 ` Eric Auger
2019-02-28 16:01 ` [Qemu-arm] " Igor Mammedov
2019-02-28 16:01 ` [Qemu-devel] " Igor Mammedov
2019-02-28 15:03 ` [Qemu-arm] [PATCH v10 08/10] hw/arm/virt: Implement kvm_type function for 4.0 machine Eric Auger
2019-02-28 15:03 ` [Qemu-devel] " Eric Auger
2019-02-28 16:19 ` [Qemu-arm] " Igor Mammedov
2019-02-28 16:19 ` [Qemu-devel] " Igor Mammedov
2019-03-01 9:45 ` Auger Eric
2019-03-01 9:45 ` Auger Eric
2019-02-28 15:03 ` [Qemu-devel] [PATCH v10 09/10] hw/arm/virt: Check the VCPU PA range in TCG mode Eric Auger
2019-02-28 15:03 ` Eric Auger
2019-02-28 15:03 ` [Qemu-arm] [PATCH v10 10/10] hw/arm/virt: Bump the 255GB initial RAM limit Eric Auger
2019-02-28 15:03 ` [Qemu-devel] " Eric Auger
2019-02-28 16:29 ` Igor Mammedov [this message]
2019-02-28 16:29 ` Igor Mammedov
2019-03-01 10:08 ` [Qemu-arm] " Auger Eric
2019-03-01 10:08 ` [Qemu-devel] " Auger Eric
2019-03-01 10:29 ` [Qemu-arm] " Igor Mammedov
2019-03-01 10:29 ` [Qemu-devel] " Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190228172938.1993ed57@redhat.com \
--to=imammedo@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=drjones@redhat.com \
--cc=eric.auger.pro@gmail.com \
--cc=eric.auger@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shameerali.kolothum.thodi@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.