From: Igor Mammedov <imammedo@redhat.com>
To: Salil Mehta <salil.mehta@huawei.com>
Cc: "salil.mehta@opnsrc.net" <salil.mehta@opnsrc.net>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
"mst@redhat.com" <mst@redhat.com>,
"maz@kernel.org" <maz@kernel.org>,
"jean-philippe@linaro.org" <jean-philippe@linaro.org>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
"lpieralisi@kernel.org" <lpieralisi@kernel.org>,
"peter.maydell@linaro.org" <peter.maydell@linaro.org>,
"richard.henderson@linaro.org" <richard.henderson@linaro.org>,
"armbru@redhat.com" <armbru@redhat.com>,
"andrew.jones@linux.dev" <andrew.jones@linux.dev>,
"david@redhat.com" <david@redhat.com>,
"philmd@linaro.org" <philmd@linaro.org>,
"eric.auger@redhat.com" <eric.auger@redhat.com>,
"will@kernel.org" <will@kernel.org>,
"ardb@kernel.org" <ardb@kernel.org>,
"oliver.upton@linux.dev" <oliver.upton@linux.dev>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"gshan@redhat.com" <gshan@redhat.com>,
"rafael@kernel.org" <rafael@kernel.org>,
"borntraeger@linux.ibm.com" <borntraeger@linux.ibm.com>,
"alex.bennee@linaro.org" <alex.bennee@linaro.org>,
"gustavo.romero@linaro.org" <gustavo.romero@linaro.org>,
"npiggin@gmail.com" <npiggin@gmail.com>,
"harshpb@linux.ibm.com" <harshpb@linux.ibm.com>,
"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
"darren@os.amperecomputing.com" <darren@os.amperecomputing.com>,
"ilkka@os.amperecomputing.com" <ilkka@os.amperecomputing.com>,
"vishnu@os.amperecomputing.com" <vishnu@os.amperecomputing.com>,
"gankulkarni@os.amperecomputing.com"
<gankulkarni@os.amperecomputing.com>,
"karl.heubaum@oracle.com" <karl.heubaum@oracle.com>,
"miguel.luis@oracle.com" <miguel.luis@oracle.com>,
zhukeqian <zhukeqian1@huawei.com>,
"wangxiongfeng (C)" <wangxiongfeng2@huawei.com>,
"wangyanan (Y)" <wangyanan55@huawei.com>,
"Wangzhou (B)" <wangzhou1@hisilicon.com>,
Linuxarm <linuxarm@huawei.com>,
"jiakernel2@gmail.com" <jiakernel2@gmail.com>,
"maobibo@loongson.cn" <maobibo@loongson.cn>,
"lixianglai@loongson.cn" <lixianglai@loongson.cn>,
"shahuang@redhat.com" <shahuang@redhat.com>,
"zhao1.liu@intel.com" <zhao1.liu@intel.com>
Subject: Re: [PATCH RFC V6 11/24] hw/arm/acpi: MADT change to size the guest with possible vCPUs
Date: Tue, 7 Oct 2025 14:20:16 +0200 [thread overview]
Message-ID: <20251007142016.3ed85bff@fedora> (raw)
In-Reply-To: <0175e40f70424dd9a29389b8a4f16c42@huawei.com>
On Tue, 7 Oct 2025 11:34:48 +0000
Salil Mehta <salil.mehta@huawei.com> wrote:
> Hi Igor,
>
> > From: Igor Mammedov <imammedo@redhat.com>
> > Sent: Friday, October 3, 2025 4:09 PM
> > To: salil.mehta@opnsrc.net
> >
> > On Wed, 1 Oct 2025 01:01:14 +0000
> > salil.mehta@opnsrc.net wrote:
> >
> > > From: Salil Mehta <salil.mehta@huawei.com>
> > >
> > > When QEMU builds the MADT table, modifications are needed to include
> > > information about possible vCPUs that are exposed as ACPI-disabled (i.e.,
> > `_STA.Enabled=0`).
> > > This new information will help the guest kernel pre-size its resources
> > > during boot time. Pre-sizing based on possible vCPUs will facilitate
> > > the future hot-plugging of the currently disabled vCPUs.
> > >
> > > Additionally, this change addresses updates to the ACPI MADT GIC CPU
> > > interface flags, as introduced in the UEFI ACPI 6.5 specification [1].
> > > These updates enable deferred virtual CPU onlining in the guest kernel.
> > >
> > > Reference:
> > > [1] 5.2.12.14. GIC CPU Interface (GICC) Structure (Table 5.37 GICC CPU
> > Interface Flags)
> > > Link:
> > >
> > https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.h
> > tm
> > > l#gic-cpu-interface-gicc-structure
> > >
> > > Co-developed-by: Keqian Zhu <zhukeqian1@huawei.com>
> > > Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
> > > Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
> > > ---
> > > hw/arm/virt-acpi-build.c | 40 ++++++++++++++++++++++++++++++++++-
> > -----
> > > hw/core/machine.c | 14 ++++++++++++++
> > > include/hw/boards.h | 20 ++++++++++++++++++++
> > > 3 files changed, 68 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c index
> > > b01fc4f8ef..7c24dd6369 100644
> > > --- a/hw/arm/virt-acpi-build.c
> > > +++ b/hw/arm/virt-acpi-build.c
> > > @@ -760,6 +760,32 @@ static void build_append_gicr(GArray *table_data,
> > uint64_t base, uint32_t size)
> > > build_append_int_noprefix(table_data, size, 4); /* Discovery
> > > Range Length */ }
> > >
> > > +static uint32_t virt_acpi_get_gicc_flags(CPUState *cpu) {
> > > + MachineClass *mc = MACHINE_GET_CLASS(qdev_get_machine());
> > > + const uint32_t GICC_FLAG_ENABLED = BIT(0);
> > > + const uint32_t GICC_FLAG_ONLINE_CAPABLE = BIT(3);
> > > +
> > > + /* ARM architecture does not support vCPU hotplug yet */
> > > + if (!cpu) {
> > > + return 0;
> > > + }
> > > +
> > > + /*
> > > + * If the machine does not support online-capable CPUs, report the
> > GICC as
> > > + * 'enabled' only.
> > > + */
> > > + if (!mc->has_online_capable_cpus) {
> > > + return GICC_FLAG_ENABLED;
> > > + }
> > > +
> > > + /*
> > > + * ACPI 6.5, 5.2.12.14 (GICC): mark the boot CPU 'enabled' and all others
> > > + * 'online-capable'.
> > > + */
> > > + return (cpu == first_cpu) ? GICC_FLAG_ENABLED :
> > > +GICC_FLAG_ONLINE_CAPABLE; }
> > > +
> > > static void
> > > build_madt(GArray *table_data, BIOSLinker *linker, VirtMachineState
> > > *vms) { @@ -785,12 +811,14 @@ build_madt(GArray *table_data,
> > > BIOSLinker *linker, VirtMachineState *vms)
> > > build_append_int_noprefix(table_data, vms->gic_version, 1);
> > > build_append_int_noprefix(table_data, 0, 3); /* Reserved */
> > >
> > > - for (i = 0; i < MACHINE(vms)->smp.cpus; i++) {
> > > - ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(i));
> > > + for (i = 0; i < MACHINE(vms)->smp.max_cpus; i++) {
> > ^^^^^^^^^^^^
> > > + CPUState *cpu = machine_get_possible_cpu(i);
> > ...
> > > + CPUArchId *archid = machine_get_possible_cpu_arch_id(i);
> >
> > what complexity above adds? /and then you say creating instantiating ARM
> > VM is slow./
> >
> > I'd drop machine_get_possible_cpu/machine_get_possible_cpu_arch_id
> > altogether and mimic what acpi_build_madt() does.
>
>
> We can do that here but I need this function elsewhere in the monitor code as well
> to iterate over the possible CPUs and if I remember correctly I was getting compilation
> errors there. But I will check if this can be removed.
>
> I would like to keep machine_get_possible_cpu().
if you did iteration with this helper over CPUs, you'd basically introducing
^2 complexity at that point.
But that's details, we will sort it out eventually.
>
> I think you've misunderstood the reason of the boot time delay mentioned to you in RFC V5.
> It is because of the realization leg i.e. qdev_relaize(), of the vCPU and not because of this
> initialization leg
I did misunderstood wrt slow vcpus creation.
I did object to lazy creation in general, and well I still dislike it.
For more on this topic see my reply to cover letter, let continue discussion there
about that.
>
>
> >
> > > + uint32_t flags = virt_acpi_get_gicc_flags(cpu);
> > > + uint64_t mpidr = archid->arch_id;
> > >
> > > if (vms->gic_version == VIRT_GIC_VERSION_2) {
> > > physical_base_address = memmap[VIRT_GIC_CPU].base; @@
> > > -805,7 +833,7 @@ build_madt(GArray *table_data, BIOSLinker *linker,
> > VirtMachineState *vms)
> > > build_append_int_noprefix(table_data, i, 4); /* GIC ID */
> > > build_append_int_noprefix(table_data, i, 4); /* ACPI Processor UID
> > */
> > > /* Flags */
> > > - build_append_int_noprefix(table_data, 1, 4); /* Enabled */
> > > + build_append_int_noprefix(table_data, flags, 4);
> > > /* Parking Protocol Version */
> > > build_append_int_noprefix(table_data, 0, 4);
> > > /* Performance Interrupt GSIV */ @@ -819,7 +847,7 @@
> > > build_madt(GArray *table_data, BIOSLinker *linker, VirtMachineState
> > *vms)
> > > build_append_int_noprefix(table_data, vgic_interrupt, 4);
> > > build_append_int_noprefix(table_data, 0, 8); /* GICR Base
> > Address*/
> > > /* MPIDR */
> > > - build_append_int_noprefix(table_data,
> > arm_cpu_mp_affinity(armcpu), 8);
> > > + build_append_int_noprefix(table_data, mpidr, 8);
> > > /* Processor Power Efficiency Class */
> > > build_append_int_noprefix(table_data, 0, 1);
> > > /* Reserved */
> > > diff --git a/hw/core/machine.c b/hw/core/machine.c index
> > > 69d5632464..65388d859a 100644
> > > --- a/hw/core/machine.c
> > > +++ b/hw/core/machine.c
> > > @@ -1383,6 +1383,20 @@ CPUState *machine_get_possible_cpu(int64_t
> > cpu_index)
> > > return NULL;
> > > }
> > >
> > > +CPUArchId *machine_get_possible_cpu_arch_id(int64_t cpu_index) {
> > > + MachineState *ms = MACHINE(qdev_get_machine());
> > > + CPUArchIdList *possible_cpus = ms->possible_cpus;
> > > +
> > > + for (int i = 0; i < possible_cpus->len; i++) {
> > > + if (possible_cpus->cpus[i].cpu &&
> > > + possible_cpus->cpus[i].cpu->cpu_index == cpu_index) {
> > > + return &possible_cpus->cpus[i];
> > > + }
> > > + }
> > > + return NULL;
> > > +}
> > > +
> > > static char *cpu_slot_to_string(const CPUArchId *cpu) {
> > > GString *s = g_string_new(NULL);
> > > diff --git a/include/hw/boards.h b/include/hw/boards.h index
> > > 3ff77a8b3a..fe51ca58bf 100644
> > > --- a/include/hw/boards.h
> > > +++ b/include/hw/boards.h
> > > @@ -461,6 +461,26 @@ struct MachineState {
> > > bool acpi_spcr_enabled;
> > > };
> > >
> > > +/*
> > > + * machine_get_possible_cpu_arch_id:
> > > + * @cpu_index: logical cpu_index to search for
> > > + *
> > > + * Return a pointer to the CPUArchId entry matching the given
> > > +@cpu_index
> > > + * in the current machine's MachineState. The possible_cpus array
> > > +holds
> > > + * the full set of CPUs that the machine could support, including
> > > +those
> > > + * that may be created as disabled or taken offline.
> > > + *
> > > + * The slot index in ms->possible_cpus[] is always sequential, but
> > > +the
> > > + * logical cpu_index values are assigned by QEMU and may or may not
> > > +be
> > > + * sequential depending on the implementation of a particular machine.
> > > + * Direct indexing by cpu_index is therefore unsafe in general. This
> > > + * helper performs a linear search of the possible_cpus array to find
> > > + * the matching entry.
> > > + *
> > > + * Returns: pointer to the matching CPUArchId, or NULL if not found.
> > > + */
> > > +CPUArchId *machine_get_possible_cpu_arch_id(int64_t cpu_index);
> > > +
> > > /*
> > > * The macros which follow are intended to facilitate the
> > > * definition of versioned machine types, using a somewhat
> >
>
next prev parent reply other threads:[~2025-10-07 12:22 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-01 1:01 [PATCH RFC V6 00/24] Support of Virtual CPU Hotplug-like Feature for ARMv8+ Arch salil.mehta
2025-10-01 1:01 ` [PATCH RFC V6 01/24] hw/core: Introduce administrative power-state property and its accessors salil.mehta
2025-10-09 10:48 ` Miguel Luis
2025-10-01 1:01 ` [PATCH RFC V6 02/24] hw/core, qemu-options.hx: Introduce 'disabledcpus' SMP parameter salil.mehta
2025-10-09 11:28 ` Miguel Luis
2025-10-09 13:17 ` Igor Mammedov
2025-10-09 11:51 ` Markus Armbruster
2025-10-01 1:01 ` [PATCH RFC V6 03/24] hw/arm/virt: Clamp 'maxcpus' as-per machine's vCPU deferred online-capability salil.mehta
2025-10-09 12:32 ` Miguel Luis
2025-10-09 13:11 ` Igor Mammedov
2025-10-01 1:01 ` [PATCH RFC V6 04/24] arm/virt, target/arm: Add new ARMCPU {socket, cluster, core, thread}-id property salil.mehta
2025-10-01 1:01 ` [PATCH RFC V6 05/24] arm/virt, kvm: Pre-create KVM vCPUs for 'disabled' QOM vCPUs at machine init salil.mehta
2025-10-01 1:01 ` [PATCH RFC V6 06/24] arm/virt, gicv3: Pre-size GIC with possible " salil.mehta
2025-10-01 1:01 ` [PATCH RFC V6 07/24] arm/gicv3: Refactor CPU interface init for shared TCG/KVM use salil.mehta
2025-10-01 1:01 ` [PATCH RFC V6 08/24] arm/virt, gicv3: Guard CPU interface access for admin disabled vCPUs salil.mehta
2025-10-01 1:01 ` [PATCH RFC V6 09/24] hw/intc/arm_gicv3_common: Migrate & check 'GICv3CPUState' accessibility mismatch salil.mehta
2025-10-01 1:01 ` [PATCH RFC V6 10/24] arm/virt: Init PMU at host for all present vCPUs salil.mehta
2025-10-03 15:02 ` Igor Mammedov
2025-10-01 1:01 ` [PATCH RFC V6 11/24] hw/arm/acpi: MADT change to size the guest with possible vCPUs salil.mehta
2025-10-03 15:09 ` Igor Mammedov
[not found] ` <0175e40f70424dd9a29389b8a4f16c42@huawei.com>
2025-10-07 12:20 ` Igor Mammedov [this message]
2025-10-10 3:15 ` Salil Mehta
2025-10-01 1:01 ` [PATCH RFC V6 12/24] hw/core: Introduce generic device power-state handler interface salil.mehta
2025-10-01 1:01 ` [PATCH RFC V6 13/24] qdev: make admin power state changes trigger platform transitions via ACPI salil.mehta
2025-10-01 1:01 ` [PATCH RFC V6 14/24] arm/acpi: Introduce dedicated CPU OSPM interface for ARM-like platforms salil.mehta
2025-10-03 14:58 ` Igor Mammedov
[not found] ` <7da6a9c470684754810414f0abd23a62@huawei.com>
2025-10-07 12:06 ` Igor Mammedov
2025-10-10 3:00 ` Salil Mehta
2025-10-01 1:01 ` [PATCH RFC V6 15/24] acpi/ged: Notify OSPM of CPU administrative state changes via GED salil.mehta
2025-10-01 1:01 ` [PATCH RFC V6 16/24] arm/virt/acpi: Update ACPI DSDT Tbl to include 'Online-Capable' CPUs AML salil.mehta
2025-10-01 1:01 ` [PATCH RFC V6 17/24] hw/arm/virt, acpi/ged: Add PowerStateHandler hooks for runtime CPU state changes salil.mehta
2025-10-01 1:01 ` [PATCH RFC V6 18/24] target/arm/kvm, tcg: Handle SMCCC hypercall exits in VMM during PSCI_CPU_{ON, OFF} salil.mehta
2025-10-01 1:01 ` [PATCH RFC V6 19/24] target/arm/cpu: Add the Accessor hook to fetch ARM CPU arch-id salil.mehta
2025-10-01 1:01 ` [PATCH RFC V6 20/24] target/arm/kvm: Write vCPU's state back to KVM on cold-reset salil.mehta
2025-10-01 1:01 ` [PATCH RFC V6 21/24] hw/intc/arm-gicv3-kvm: Pause all vCPUs & cache ICC_CTLR_EL1 for userspace PSCI CPU_ON salil.mehta
2025-10-01 1:01 ` [PATCH RFC V6 22/24] monitor, qdev: Introduce 'device_set' to change admin state of existing devices salil.mehta
2025-10-09 8:55 ` [PATCH RFC V6 22/24] monitor,qdev: " Markus Armbruster
2025-10-09 12:51 ` Igor Mammedov
2025-10-09 14:03 ` Daniel P. Berrangé
2025-10-09 14:55 ` Markus Armbruster
2025-10-09 15:19 ` Peter Maydell
2025-10-10 4:59 ` Markus Armbruster
2025-10-01 1:01 ` [PATCH RFC V6 23/24] monitor, qapi: add 'info cpus-powerstate' and QMP query (Admin + Oper states) salil.mehta
2025-10-09 11:53 ` [PATCH RFC V6 23/24] monitor,qapi: " Markus Armbruster
2025-10-01 1:01 ` [PATCH RFC V6 24/24] tcg: Defer TB flush for 'lazy realized' vCPUs on first region alloc salil.mehta
2025-10-01 21:34 ` Richard Henderson
2025-10-02 12:27 ` Salil Mehta via
2025-10-02 15:41 ` Richard Henderson
2025-10-07 10:14 ` Salil Mehta via
2025-10-06 14:00 ` [PATCH RFC V6 00/24] Support of Virtual CPU Hotplug-like Feature for ARMv8+ Arch Igor Mammedov
2025-10-13 0:34 ` Gavin Shan
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=20251007142016.3ed85bff@fedora \
--to=imammedo@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=andrew.jones@linux.dev \
--cc=ardb@kernel.org \
--cc=armbru@redhat.com \
--cc=borntraeger@linux.ibm.com \
--cc=darren@os.amperecomputing.com \
--cc=david@redhat.com \
--cc=eric.auger@redhat.com \
--cc=gankulkarni@os.amperecomputing.com \
--cc=gshan@redhat.com \
--cc=gustavo.romero@linaro.org \
--cc=harshpb@linux.ibm.com \
--cc=ilkka@os.amperecomputing.com \
--cc=jean-philippe@linaro.org \
--cc=jiakernel2@gmail.com \
--cc=jonathan.cameron@huawei.com \
--cc=karl.heubaum@oracle.com \
--cc=linux@armlinux.org.uk \
--cc=linuxarm@huawei.com \
--cc=lixianglai@loongson.cn \
--cc=lpieralisi@kernel.org \
--cc=maobibo@loongson.cn \
--cc=maz@kernel.org \
--cc=miguel.luis@oracle.com \
--cc=mst@redhat.com \
--cc=npiggin@gmail.com \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rafael@kernel.org \
--cc=richard.henderson@linaro.org \
--cc=salil.mehta@huawei.com \
--cc=salil.mehta@opnsrc.net \
--cc=shahuang@redhat.com \
--cc=vishnu@os.amperecomputing.com \
--cc=wangxiongfeng2@huawei.com \
--cc=wangyanan55@huawei.com \
--cc=wangzhou1@hisilicon.com \
--cc=will@kernel.org \
--cc=zhao1.liu@intel.com \
--cc=zhukeqian1@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).