From: Salil Mehta via <qemu-devel@nongnu.org>
To: Gavin Shan <gshan@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
"mst@redhat.com" <mst@redhat.com>
Cc: "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>,
"imammedo@redhat.com" <imammedo@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>,
"rafael@kernel.org" <rafael@kernel.org>,
"borntraeger@linux.ibm.com" <borntraeger@linux.ibm.com>,
"alex.bennee@linaro.org" <alex.bennee@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>,
"karl.heubaum@oracle.com" <karl.heubaum@oracle.com>,
"miguel.luis@oracle.com" <miguel.luis@oracle.com>,
"salil.mehta@opnsrc.net" <salil.mehta@opnsrc.net>,
zhukeqian <zhukeqian1@huawei.com>,
"wangxiongfeng (C)" <wangxiongfeng2@huawei.com>,
"wangyanan (Y)" <wangyanan55@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>,
Linuxarm <linuxarm@huawei.com>
Subject: RE: [PATCH RFC V3 11/29] arm/virt: Create GED dev before *disabled* CPU Objs are destroyed
Date: Tue, 20 Aug 2024 17:10:59 +0000 [thread overview]
Message-ID: <1b6f5681cd5b4d1c887c5423faf5875f@huawei.com> (raw)
In-Reply-To: <52ae18ca-0a5a-44d4-95f5-56cfc7a035a8@redhat.com>
Hi Gavin,
> From: Gavin Shan <gshan@redhat.com>
> Sent: Tuesday, August 20, 2024 1:22 AM
> To: Salil Mehta <salil.mehta@huawei.com>; qemu-devel@nongnu.org;
> qemu-arm@nongnu.org; mst@redhat.com
>
> Hi Salil,
>
> On 8/19/24 10:10 PM, Salil Mehta wrote:
> >> From: Gavin Shan <gshan@redhat.com>
> >> Sent: Tuesday, August 13, 2024 2:05 AM
> >> To: Salil Mehta <salil.mehta@huawei.com>; qemu-devel@nongnu.org;
> >> qemu-arm@nongnu.org; mst@redhat.com
> >>
> >> On 6/14/24 9:36 AM, Salil Mehta wrote:
> >> > ACPI CPU hotplug state (is_present=_STA.PRESENT,
> >> > is_enabled=_STA.ENABLED) for all the possible vCPUs MUST be
> >> > initialized during machine init. This is done during the creation of
> >> > the GED device. VMM/Qemu MUST expose/fake the ACPI state of the
> >> > disabled vCPUs to the Guest kernel as 'present' (_STA.PRESENT) always
> >> > i.e. ACPI persistent. if the 'disabled' vCPU objectes are destroyed
> >> > before the GED device has been created then their ACPI hotplug state
> >> > might not get initialized correctly as acpi_persistent flag is part of the
> >> CPUState. This will expose wrong status of the unplugged vCPUs to the
> >> Guest kernel.
> >> >
> >> > Hence, moving the GED device creation before disabled vCPU objects get
> >> > destroyed as part of the post CPU init routine.
> >> >
> >> > Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
> >> > ---
> >> > hw/arm/virt.c | 10 +++++++---
> >> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/hw/arm/virt.c b/hw/arm/virt.c index
> >> > 918bcb9a1b..5f98162587 100644
> >> > --- a/hw/arm/virt.c
> >> > +++ b/hw/arm/virt.c
> >> > @@ -2467,6 +2467,12 @@ static void machvirt_init(MachineState
> >> > *machine)
> >> >
> >> > create_gic(vms, sysmem);
> >> >
> >> > + has_ged = has_ged && aarch64 && firmware_loaded &&
> >> > + virt_is_acpi_enabled(vms);
> >> > + if (has_ged) {
> >> > + vms->acpi_dev = create_acpi_ged(vms);
> >> > + }
> >> > +
> >> > virt_cpu_post_init(vms, sysmem);
> >> >
> >> > fdt_add_pmu_nodes(vms);
> >> > @@ -2489,9 +2495,7 @@ static void machvirt_init(MachineState
> >> *machine)
> >> >
> >> > create_pcie(vms);
> >> >
> >> > - if (has_ged && aarch64 && firmware_loaded &&
> >> virt_is_acpi_enabled(vms)) {
> >> > - vms->acpi_dev = create_acpi_ged(vms);
> >> > - } else {
> >> > + if (!has_ged) {
> >> > create_gpio_devices(vms, VIRT_GPIO, sysmem);
> >> > }
> >> >
> >>
> >> It's likely the GPIO device can be created before those disabled CPU objects
> >> are destroyed. It means the whole chunk of code can be moved together, I
> >> think.
> >
> > I was not totally sure of this. Hence, kept the order of the rest like
> > that. I can definitely check again if we can do that to reduce the change.
> >
>
> @has_ged is the equivalent to '!vmc->no_ged' initially and then it's
> overrided by the following changes in this patch. The syntax of @has_ged
> has been changed and it's not the best name to match the changes. There
> are two solutions: (1) Rename @has_ged to something meaningful and
> matching with the changes; (2) Move the whole chunk of codes, which I
> preferred. The GPIO device and GED device are supplementing to each
> other, meaning GPIO device will be created when GED device has been
> disallowed.
>
> has_ged = has_ged && aarch64 && firmware_loaded &&
> virt_is_acpi_enabled(vms);
>
> The code to be moved together in virt.c since they're correlated:
>
> if (has_ged && aarch64 && firmware_loaded &&
> virt_is_acpi_enabled(vms)) {
> vms->acpi_dev = create_acpi_ged(vms);
> } else {
> create_gpio_devices(vms, VIRT_GPIO, sysmem);
> }
>
> if (vms->secure && !vmc->no_secure_gpio) {
> create_gpio_devices(vms, VIRT_SECURE_GPIO, secure_sysmem);
> }
>
> /* connect powerdown request */
> vms->powerdown_notifier.notify = virt_powerdown_req;
> qemu_register_powerdown_notifier(&vms->powerdown_notifier);
If there is no dependency then we can completely move before virt_cpu_post_init().
I'll get back to you on this.
Thanks
Salil.
>
> Thanks,
> Gavin
>
>
>
>
next prev parent reply other threads:[~2024-08-20 17:11 UTC|newest]
Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-13 23:36 [PATCH RFC V3 00/29] Support of Virtual CPU Hotplug for ARMv8 Arch Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 01/29] arm/virt, target/arm: Add new ARMCPU {socket, cluster, core, thread}-id property Salil Mehta via
2024-08-12 4:35 ` [PATCH RFC V3 01/29] arm/virt,target/arm: Add new ARMCPU {socket,cluster,core,thread}-id property Gavin Shan
2024-08-12 8:15 ` Igor Mammedov
2024-08-13 0:31 ` Gavin Shan
2024-08-19 12:07 ` Salil Mehta via
2024-08-19 11:53 ` Salil Mehta via
2024-09-04 14:42 ` zhao1.liu
2024-09-04 17:37 ` Salil Mehta via
2024-09-09 15:28 ` Zhao Liu
2024-09-10 11:01 ` Salil Mehta via
2024-09-11 11:35 ` Jonathan Cameron via
2024-09-11 12:25 ` Salil Mehta
2024-06-13 23:36 ` [PATCH RFC V3 02/29] cpu-common: Add common CPU utility for possible vCPUs Salil Mehta via
2024-07-04 3:12 ` Nicholas Piggin
2024-08-12 4:59 ` Gavin Shan
2024-08-12 5:41 ` 回复: " liu ping
2024-06-13 23:36 ` [PATCH RFC V3 03/29] hw/arm/virt: Limit number of possible vCPUs for unsupported Accel or GIC Type Salil Mehta via
2024-08-12 5:09 ` Gavin Shan
2024-06-13 23:36 ` [PATCH RFC V3 04/29] hw/arm/virt: Move setting of common CPU properties in a function Salil Mehta via
2024-08-12 5:19 ` Gavin Shan
2024-06-13 23:36 ` [PATCH RFC V3 05/29] arm/virt, target/arm: Machine init time change common to vCPU {cold|hot}-plug Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 06/29] arm/virt, kvm: Pre-create disabled possible vCPUs @machine init Salil Mehta via
2024-08-13 0:58 ` [PATCH RFC V3 06/29] arm/virt,kvm: " Gavin Shan
2024-08-19 5:31 ` Gavin Shan
2024-08-19 13:06 ` Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 07/29] arm/virt, gicv3: Changes to pre-size GIC with possible vcpus " Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 08/29] arm/virt: Init PMU at host for all possible vcpus Salil Mehta via
2024-07-04 3:07 ` Nicholas Piggin
2024-07-04 12:03 ` Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 09/29] arm/acpi: Enable ACPI support for vcpu hotplug Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 10/29] arm/virt: Add cpu hotplug events to GED during creation Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 11/29] arm/virt: Create GED dev before *disabled* CPU Objs are destroyed Salil Mehta via
2024-08-13 1:04 ` Gavin Shan
2024-08-19 12:10 ` Salil Mehta via
2024-08-20 0:22 ` Gavin Shan
2024-08-20 17:10 ` Salil Mehta via [this message]
2024-06-13 23:36 ` [PATCH RFC V3 12/29] arm/virt/acpi: Build CPUs AML with CPU Hotplug support Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 13/29] arm/virt: Make ARM vCPU *present* status ACPI *persistent* Salil Mehta via
2024-07-04 2:49 ` Nicholas Piggin
2024-07-04 11:23 ` Salil Mehta via
2024-07-05 0:08 ` Nicholas Piggin
2024-06-13 23:36 ` [PATCH RFC V3 14/29] hw/acpi: ACPI/AML Changes to reflect the correct _STA.{PRES, ENA} Bits to Guest Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 15/29] hw/arm: MADT Tbl change to size the guest with possible vCPUs Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 16/29] hw/acpi: Make _MAT method optional Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 17/29] arm/virt: Release objects for *disabled* possible vCPUs after init Salil Mehta via
2024-08-13 1:17 ` Gavin Shan
2024-08-19 12:21 ` Salil Mehta via
2024-08-20 0:05 ` Gavin Shan
2024-08-20 16:40 ` Salil Mehta via
2024-08-21 6:25 ` Gavin Shan
2024-08-21 10:23 ` Salil Mehta via
2024-08-21 13:32 ` Gavin Shan
2024-08-22 10:58 ` Salil Mehta via
2024-08-23 10:52 ` Gavin Shan
2024-08-23 13:17 ` Salil Mehta via
2024-08-24 10:03 ` Gavin Shan
2024-06-13 23:36 ` [PATCH RFC V3 18/29] arm/virt: Add/update basic hot-(un)plug framework Salil Mehta via
2024-08-13 1:21 ` Gavin Shan
2024-08-19 12:30 ` Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 19/29] arm/virt: Changes to (un)wire GICC<->vCPU IRQs during hot-(un)plug Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 20/29] hw/arm, gicv3: Changes to update GIC with vCPU hot-plug notification Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 21/29] hw/intc/arm-gicv3*: Changes required to (re)init the vCPU register info Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 22/29] arm/virt: Update the guest(via GED) about CPU hot-(un)plug events Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 23/29] hw/arm: Changes required for reset and to support next boot Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 24/29] target/arm: Add support of *unrealize* ARMCPU during vCPU Hot-unplug Salil Mehta via
2024-08-16 15:37 ` Alex Bennée
2024-08-16 15:50 ` Peter Maydell
2024-08-16 17:00 ` Peter Maydell
2024-08-19 12:59 ` Salil Mehta via
2024-08-19 13:43 ` Peter Maydell
2024-08-19 12:58 ` Salil Mehta via
2024-08-19 13:46 ` Peter Maydell
2024-08-20 15:34 ` Salil Mehta via
2024-08-19 12:35 ` Salil Mehta via
2024-08-28 20:23 ` Gustavo Romero
2024-09-04 13:53 ` Salil Mehta via
2024-06-13 23:36 ` [PATCH RFC V3 25/29] target/arm/kvm: Write CPU state back to KVM on reset Salil Mehta via
2024-07-04 3:27 ` Nicholas Piggin
2024-07-04 12:27 ` Salil Mehta via
2024-06-14 0:15 ` [PATCH RFC V3 26/29] target/arm/kvm, tcg: Register/Handle SMCCC hypercall exits to VMM/Qemu Salil Mehta via
2024-06-14 0:18 ` [PATCH RFC V3 27/29] hw/arm: Support hotplug capability check using _OSC method Salil Mehta via
2024-06-14 0:19 ` [PATCH RFC V3 28/29] tcg/mttcg: enable threads to unregister in tcg_ctxs[] Salil Mehta via
2024-06-14 0:20 ` [PATCH RFC V3 29/29] hw/arm/virt: Expose cold-booted CPUs as MADT GICC Enabled Salil Mehta via
2024-06-26 9:53 ` [PATCH RFC V3 00/29] Support of Virtual CPU Hotplug for ARMv8 Arch Vishnu Pajjuri
2024-06-26 18:01 ` Salil Mehta via
2024-07-01 11:38 ` Miguel Luis
2024-07-01 16:30 ` Salil Mehta via
2024-08-07 9:53 ` Gavin Shan
2024-08-07 13:27 ` Salil Mehta via
2024-08-07 16:07 ` Salil Mehta via
2024-08-08 5:00 ` Gavin Shan
2024-08-07 23:41 ` Gavin Shan
2024-08-07 23:48 ` Salil Mehta via
2024-08-08 0:29 ` Gavin Shan
2024-08-08 4:15 ` Gavin Shan
2024-08-08 8:39 ` Salil Mehta via
2024-08-08 8:36 ` Salil Mehta via
2024-08-28 20:35 ` Gustavo Romero
2024-08-29 9:59 ` Alex Bennée
2024-09-04 14:24 ` Salil Mehta via
2024-09-04 15:45 ` Alex Bennée
2024-09-04 15:59 ` Salil Mehta via
2024-09-06 15:06 ` Salil Mehta via
2024-09-04 14:03 ` Salil Mehta via
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=1b6f5681cd5b4d1c887c5423faf5875f@huawei.com \
--to=qemu-devel@nongnu.org \
--cc=alex.bennee@linaro.org \
--cc=andrew.jones@linux.dev \
--cc=ardb@kernel.org \
--cc=borntraeger@linux.ibm.com \
--cc=darren@os.amperecomputing.com \
--cc=david@redhat.com \
--cc=eric.auger@redhat.com \
--cc=gshan@redhat.com \
--cc=harshpb@linux.ibm.com \
--cc=ilkka@os.amperecomputing.com \
--cc=imammedo@redhat.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=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=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).