From: Andrew Jones <drjones@redhat.com>
To: Ying Fang <fangying1@huawei.com>
Cc: peter.maydell@linaro.org, salil.mehta@huawei.com,
zhang.zhanghailiang@huawei.com, mst@redhat.com,
qemu-devel@nongnu.org, shannon.zhaosl@gmail.com,
qemu-arm@nongnu.org, alistair.francis@wdc.com,
imammedo@redhat.com
Subject: Re: [RFC PATCH 3/5] hw/arm/virt-acpi-build: distinguish possible and present cpus
Date: Thu, 25 Feb 2021 12:26:36 +0100 [thread overview]
Message-ID: <20210225112636.qiahzzhjd6jfrzoz@kamzik.brq.redhat.com> (raw)
In-Reply-To: <20210225085627.2263-4-fangying1@huawei.com>
On Thu, Feb 25, 2021 at 04:56:25PM +0800, Ying Fang 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 in madt.
> Furthermore, it is also needed if we are going to support CPU
> hotplug in the future.
>
> This patch is a rework based on Andrew Jones's contribution at
> https://lists.gnu.org/archive/html/qemu-arm/2018-07/msg00076.html
>
> Signed-off-by: Ying Fang <fangying1@huawei.com>
> ---
> hw/arm/virt-acpi-build.c | 14 ++++++++++----
> hw/arm/virt.c | 2 ++
> 2 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index f9c9df916c..bb91152fe2 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -61,13 +61,16 @@
>
> static void acpi_dsdt_add_cpus(Aml *scope, VirtMachineState *vms)
> {
> - MachineState *ms = MACHINE(vms);
> + CPUArchIdList *possible_cpus = MACHINE(vms)->possible_cpus;
> uint16_t i;
>
> - for (i = 0; i < ms->smp.cpus; i++) {
> + for (i = 0; i < possible_cpus->len; i++) {
Switching from ms->smp.cpus to possible_cpus->len makes some sense
here, since we're going to be using possible_cpus->cpus[] inside
the loop. Otherwise, I'd prefer switching to ms->smp.max_cpus.
> 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 (possible_cpus->cpus[i].cpu == NULL) {
> + aml_append(dev, aml_name_decl("_STA", aml_int(0)));
> + }
> aml_append(scope, dev);
> }
> }
> @@ -479,6 +482,7 @@ build_madt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> const int *irqmap = vms->irqmap;
> AcpiMadtGenericDistributor *gicd;
> AcpiMadtGenericMsiFrame *gic_msi;
> + CPUArchIdList *possible_cpus = MACHINE(vms)->possible_cpus;
> int i;
>
> acpi_data_push(table_data, sizeof(AcpiMultipleApicTable));
> @@ -489,7 +493,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 < MACHINE(vms)->smp.cpus; i++) {
> + for (i = 0; i < possible_cpus->len; i++) {
Same comment as above.
> AcpiMadtGenericCpuInterface *gicc = acpi_data_push(table_data,
> sizeof(*gicc));
> ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(i));
> @@ -504,7 +508,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 (possible_cpus->cpus[i].cpu != NULL) {
> + 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));
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index c133b342b8..75659502e2 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -2047,6 +2047,8 @@ static void machvirt_init(MachineState *machine)
>
> qdev_realize(DEVICE(cpuobj), NULL, &error_fatal);
> object_unref(cpuobj);
> + /* Initialize cpu member here since cpu hotplug is not supported yet */
> + machine->possible_cpus->cpus[n].cpu = cpuobj;
This feels like we're violating a possible_cpus abstraction. Igor?
Also, it's using cpuobj after unrefing it.
> }
> fdt_add_timer_nodes(vms);
> fdt_add_cpu_nodes(vms);
> --
> 2.23.0
>
>
Thanks,
drew
next prev parent reply other threads:[~2021-02-25 11:28 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-25 8:56 [RFC PATCH 0/5] hw/arm/virt: Introduce cpu topology support Ying Fang
2021-02-25 8:56 ` [RFC PATCH 1/5] device_tree: Add qemu_fdt_add_path Ying Fang
2021-02-25 11:03 ` Andrew Jones
2021-02-25 12:54 ` Ying Fang
2021-02-25 13:25 ` Andrew Jones
2021-02-25 13:39 ` Ying Fang
2021-02-25 8:56 ` [RFC PATCH 2/5] hw/arm/virt: Add cpu-map to device tree Ying Fang
2021-02-25 11:16 ` Andrew Jones
2021-02-25 13:18 ` Ying Fang
2021-02-25 14:30 ` Andrew Jones
2021-02-25 8:56 ` [RFC PATCH 3/5] hw/arm/virt-acpi-build: distinguish possible and present cpus Ying Fang
2021-02-25 11:26 ` Andrew Jones [this message]
2021-02-25 8:56 ` [RFC PATCH 4/5] hw/acpi/aml-build: add processor hierarchy node structure Ying Fang
2021-02-25 11:47 ` Andrew Jones
2021-02-26 2:23 ` Ying Fang
2021-03-01 9:39 ` Andrew Jones
2021-03-01 15:50 ` Michael S. Tsirkin
2021-03-04 7:09 ` Ying Fang
2021-02-25 8:56 ` [RFC PATCH 5/5] hw/arm/virt-acpi-build: add PPTT table Ying Fang
2021-02-25 11:38 ` Andrew Jones
2021-02-26 2:26 ` Ying Fang
2021-02-25 12:02 ` [RFC PATCH 0/5] hw/arm/virt: Introduce cpu topology support Andrew Jones
2021-02-26 8:41 ` Ying Fang
2021-03-01 9:48 ` Andrew Jones
2021-03-05 6:14 ` Ying Fang
[not found] ` <20210310092059.blt3yymqi2eyc2ua@kamzik.brq.redhat.com>
2021-03-10 9:43 ` 答复: " fangying
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=20210225112636.qiahzzhjd6jfrzoz@kamzik.brq.redhat.com \
--to=drjones@redhat.com \
--cc=alistair.francis@wdc.com \
--cc=fangying1@huawei.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=salil.mehta@huawei.com \
--cc=shannon.zhaosl@gmail.com \
--cc=zhang.zhanghailiang@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).