qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Shannon Zhao <zhaoshenglong@huawei.com>,
	eric.auger.pro@gmail.com, qemu-devel@nongnu.org,
	qemu-arm@nongnu.org, peter.maydell@linaro.org
Cc: wei@redhat.com, marc.zyngier@arm.com, drjones@redhat.com,
	cdall@kernel.org
Subject: Re: [Qemu-devel] [RFC 8/8] hw/arm/virt: Allow up to 512 vcpus along with KVM VGICv3
Date: Wed, 28 Mar 2018 08:47:36 +0200	[thread overview]
Message-ID: <578156db-afbd-a4d7-3899-ec96e2cfd8fb@redhat.com> (raw)
In-Reply-To: <5ABB13BC.8060809@huawei.com>

Hi Shannon,

On 28/03/18 06:02, Shannon Zhao wrote:
> 
> 
> On 2018/3/27 22:15, Eric Auger wrote:
>> With KVM acceleration and if KVM VGICV3 supports to set multiple
>> redistributor regions, we now allow up to 512 vcpus.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>> ---
>>  hw/arm/virt.c         | 17 ++++++++++++++++-
>>  include/hw/arm/virt.h |  1 +
>>  2 files changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 8258f6f..cdb1a75 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -149,8 +149,10 @@ static const MemMapEntry a15memmap[] = {
>>      [VIRT_PCIE_PIO] =           { 0x3eff0000, 0x00010000 },
>>      [VIRT_PCIE_ECAM] =          { 0x3f000000, 0x01000000 },
>>      [VIRT_MEM] =                { 0x40000000, RAMLIMIT_BYTES },
>> +    /* Allows 512 - 123 additional vcpus (each 2x64kB) */
>> +    [VIRT_GIC_REDIST2] =        { 0x4000000000ULL, 0x30A0000LL },
> One concern that this will limit the guest ram size to RAMLIMIT_BYTES.
> If we want to support larger ram size in the future, this may be a problem.
There is comment before  #define RAMLIMIT_GB 255
saying that RAM extension should rather happen at 2TB base.
"../.. We don't want to fill all the way up to 512GB with RAM because
 * we might want it for non-RAM purposes later"

This REDIST2 region could also be allocated at the top of the [256GB -
512GB] region.

I will start working on extending the RAM as suggested by this comment.

Thanks

Eric

> 
>>      /* Second PCIe window, 512GB wide at the 512GB boundary */
>> -    [VIRT_PCIE_MMIO_HIGH] =   { 0x8000000000ULL, 0x8000000000ULL },
>> +    [VIRT_PCIE_MMIO_HIGH] =     { 0x8000000000ULL, 0x8000000000ULL },
>>  };
>>  
>>  static const int a15irqmap[] = {
>> @@ -553,6 +555,11 @@ static void create_gic(VirtMachineState *vms, qemu_irq *pic)
>>          agcc->register_redist_region((GICv3State *)gicdev,
>>                                   vms->memmap[VIRT_GIC_REDIST].base,
>>                                   vms->memmap[VIRT_GIC_REDIST].size >> 17);
>> +        if (vms->smp_cpus > 123) {
>> +            agcc->register_redist_region((GICv3State *)gicdev,
>> +                     vms->memmap[VIRT_GIC_REDIST2].base,
>> +                                 vms->memmap[VIRT_GIC_REDIST2].size >> 17);
>> +        }
>>      } else {
>>          sysbus_mmio_map(gicbusdev, 1, vms->memmap[VIRT_GIC_CPU].base);
>>      }
>> @@ -1284,6 +1291,14 @@ static void machvirt_init(MachineState *machine)
>>       */
>>      if (vms->gic_version == 3) {
>>          virt_max_cpus = vms->memmap[VIRT_GIC_REDIST].size / 0x20000;
>> +        if (kvm_max_vcpus(kvm_state) > 255) {
>> +            /*
>> +             * VGICv3 KVM device capability to set multiple redistributor
>> +             * was introduced at the same time KVM_MAX_VCPUS was bumped
>> +             * from 255 to 512
>> +             */
>> +            virt_max_cpus += vms->memmap[VIRT_GIC_REDIST2].size / 0x20000;
>> +        }
>>      } else {
>>          virt_max_cpus = GIC_NCPU;
>>      }
>> diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
>> index d168291..801a4ad 100644
>> --- a/include/hw/arm/virt.h
>> +++ b/include/hw/arm/virt.h
>> @@ -60,6 +60,7 @@ enum {
>>      VIRT_GIC_V2M,
>>      VIRT_GIC_ITS,
>>      VIRT_GIC_REDIST,
>> +    VIRT_GIC_REDIST2,
>>      VIRT_UART,
>>      VIRT_MMIO,
>>      VIRT_RTC,
>>
> 

  reply	other threads:[~2018-03-28  6:47 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-27 14:15 [Qemu-devel] [RFC 0/8] KVM/ARM: Relax the max 123 vcpus limitation along with KVM GICv3 Eric Auger
2018-03-27 14:15 ` [Qemu-devel] [RFC 1/8] linux-headers: Partial update for KVM/ARM multiple redistributor region registration Eric Auger
2018-03-27 14:15 ` [Qemu-devel] [RFC 2/8] hw/intc/arm_gicv3: Use an array of redistributor regions Eric Auger
2018-04-13 13:27   ` Peter Maydell
2018-04-13 13:36     ` Auger Eric
2018-03-27 14:15 ` [Qemu-devel] [RFC 3/8] kvm: Expose kvm_max_vcpus() Eric Auger
2018-03-27 14:15 ` [Qemu-devel] [RFC 4/8] hw/intc/arm_gicv3: Implement register_redist_region API Eric Auger
2018-04-13 13:34   ` Peter Maydell
2018-04-13 13:44     ` Auger Eric
2018-04-13 13:46       ` Peter Maydell
2018-04-13 13:56         ` Auger Eric
2018-03-27 14:15 ` [Qemu-devel] [RFC 5/8] hw/intc/arm_gicv3_kvm: Allow multiple redistributor regions Eric Auger
2018-03-27 14:15 ` [Qemu-devel] [RFC 6/8] hw/arm/virt: Allow GICv3 DT node with " Eric Auger
2018-04-13 13:36   ` Peter Maydell
2018-04-13 13:45     ` Auger Eric
2018-03-27 14:15 ` [Qemu-devel] [RFC 7/8] hw/arm/virt-acpi-build: Handle multiple GICR structures Eric Auger
2018-04-13 13:47   ` Andrew Jones
2018-04-13 13:55     ` Auger Eric
2018-03-27 14:15 ` [Qemu-devel] [RFC 8/8] hw/arm/virt: Allow up to 512 vcpus along with KVM VGICv3 Eric Auger
2018-03-28  4:02   ` Shannon Zhao
2018-03-28  6:47     ` Auger Eric [this message]
2018-04-13 13:41   ` Peter Maydell
2018-04-13 14:01     ` Auger Eric
2018-04-13 14:06       ` Peter Maydell
2018-04-13 14:11         ` Auger Eric
2018-04-16  9:19           ` Andrew Jones
2018-04-16 10:58             ` Peter Maydell

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=578156db-afbd-a4d7-3899-ec96e2cfd8fb@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=cdall@kernel.org \
    --cc=drjones@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=marc.zyngier@arm.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=wei@redhat.com \
    --cc=zhaoshenglong@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).