qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Andrew Jones <drjones@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-arm@nongnu.org, wei@redhat.com,
	peter.maydell@linaro.org, eric.auger@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH 4/6] hw/arm/virt-acpi-build: distinguish possible and present cpus
Date: Mon, 23 Jul 2018 15:28:36 +0200	[thread overview]
Message-ID: <20180723152836.47d3047f@redhat.com> (raw)
In-Reply-To: <20180704124923.32483-5-drjones@redhat.com>

On Wed,  4 Jul 2018 14:49:21 +0200
Andrew Jones <drjones@redhat.com> wrote:

> When building ACPI tables regarding CPUs we should always build
> them for the number of possible CPUs, not the number of present
> CPUs. We then ensure only the present CPUs are enabled.
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  hw/arm/virt-acpi-build.c | 20 +++++++++++++++-----
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 6ea47e258832..1d1fc824da6f 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -49,14 +49,22 @@
>  #define ARM_SPI_BASE 32
>  #define ACPI_POWER_BUTTON_DEVICE "PWRB"
>  
> -static void acpi_dsdt_add_cpus(Aml *scope, int smp_cpus)
> +static int possible_cpus(VirtMachineState *vms)
> +{
> +    return MACHINE_GET_CLASS(vms)->possible_cpu_arch_ids(MACHINE(vms))->len;
> +}
> +
> +static void acpi_dsdt_add_cpus(Aml *scope, int possible, int present)
>  {
>      uint16_t i;
>  
> -    for (i = 0; i < smp_cpus; i++) {
> +    for (i = 0; i < possible; i++) {
>          Aml *dev = aml_device("C%.03X", i);
>          aml_append(dev, aml_name_decl("_HID", aml_string("ACPI0007")));
>          aml_append(dev, aml_name_decl("_UID", aml_int(i)));
> +        if (i >= present) {

acpi_dsdt_add_cpus(Aml *scope, const CPUArchIdList *possible_cpus = mc->possible_cpu_arch_ids(machine)) {
      for (i = 0; i < possible_cpus->len; i++) {
          ...
          if (possible_cpus->cpus[i].cpu == NULL)
               aml_append(dev, aml_name_decl("_STA", aml_int(0)));
      }
}

would be better to be consistent with x86 variant (well I prefer using a single source for CPU enumeration whenever possible) and drop helper above.

> +            aml_append(dev, aml_name_decl("_STA", aml_int(0)));
> +        }
>          aml_append(scope, dev);
>      }
>  }
> @@ -650,7 +658,7 @@ build_madt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
>      gicd->base_address = cpu_to_le64(memmap[VIRT_GIC_DIST].base);
>      gicd->version = vms->gic_version;
>  
> -    for (i = 0; i < vms->smp_cpus; i++) {
> +    for (i = 0; i < possible_cpus(vms); i++) {
ditto

>          AcpiMadtGenericCpuInterface *gicc = acpi_data_push(table_data,
>                                                             sizeof(*gicc));
>          ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(i));
> @@ -663,7 +671,9 @@ build_madt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
>          gicc->cpu_interface_number = cpu_to_le32(i);
>          gicc->arm_mpidr = cpu_to_le64(armcpu->mp_affinity);
>          gicc->uid = cpu_to_le32(i);
> -        gicc->flags = cpu_to_le32(ACPI_MADT_GICC_ENABLED);
> +        if (i < vms->smp_cpus) {
> +            gicc->flags = cpu_to_le32(ACPI_MADT_GICC_ENABLED);
> +        }
>  
>          if (arm_feature(&armcpu->env, ARM_FEATURE_PMU)) {
>              gicc->performance_interrupt = cpu_to_le32(PPI(VIRTUAL_PMU_IRQ));
> @@ -763,7 +773,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
>       * the RTC ACPI device at all when using UEFI.
>       */
>      scope = aml_scope("\\_SB");
> -    acpi_dsdt_add_cpus(scope, vms->smp_cpus);
> +    acpi_dsdt_add_cpus(scope, possible_cpus(vms), vms->smp_cpus);
>      acpi_dsdt_add_uart(scope, &memmap[VIRT_UART],
>                         (irqmap[VIRT_UART] + ARM_SPI_BASE));
>      acpi_dsdt_add_flash(scope, &memmap[VIRT_FLASH]);

  reply	other threads:[~2018-07-23 13:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-04 12:49 [Qemu-devel] [RFC PATCH 0/6] hw/arm/virt: Introduce cpu topology support Andrew Jones
2018-07-04 12:49 ` [Qemu-devel] [RFC PATCH 1/6] hw/arm/virt: Add virt-3.1 machine type Andrew Jones
2018-07-23 12:22   ` Igor Mammedov
2018-08-17 14:55     ` Peter Maydell
2018-07-04 12:49 ` [Qemu-devel] [RFC PATCH 2/6] device_tree: add qemu_fdt_add_path Andrew Jones
2018-07-23 12:42   ` Igor Mammedov
2018-08-17 15:00     ` Andrew Jones
2018-07-04 12:49 ` [Qemu-devel] [RFC PATCH 3/6] hw/arm/virt: DT: add cpu-map Andrew Jones
2018-07-23 13:10   ` Igor Mammedov
2018-07-04 12:49 ` [Qemu-devel] [RFC PATCH 4/6] hw/arm/virt-acpi-build: distinguish possible and present cpus Andrew Jones
2018-07-23 13:28   ` Igor Mammedov [this message]
2018-07-04 12:49 ` [Qemu-devel] [RFC PATCH 5/6] virt-acpi-build: add PPTT table Andrew Jones
2018-07-11 12:51   ` Andrew Jones
2018-07-23 14:00   ` Igor Mammedov
2018-07-04 12:49 ` [Qemu-devel] [RFC PATCH 6/6] hw/arm/virt: cpu topology: don't allow threads Andrew Jones
2019-12-09  2:14 ` [Qemu-devel] [RFC PATCH 0/6] hw/arm/virt: Introduce cpu topology support Zengtao (B)
2019-12-10 10:13   ` Andrew Jones
2019-12-11 11:10     ` Zengtao (B)

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=20180723152836.47d3047f@redhat.com \
    --to=imammedo@redhat.com \
    --cc=drjones@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=wei@redhat.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).