From: Salil Mehta via <qemu-devel@nongnu.org>
To: Igor Mammedov <imammedo@redhat.com>
Cc: "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>,
"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>,
"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>,
"gustavo.romero@linaro.org" <gustavo.romero@linaro.org>
Subject: RE: [PATCH V1 3/4] hw/acpi: Reflect ACPI vCPU {present,enabled} states in ACPI _STA.{PRES,ENA} Bits
Date: Tue, 22 Oct 2024 23:57:55 +0000 [thread overview]
Message-ID: <a8f41af5e450446e8dd68ebf9b9305a6@huawei.com> (raw)
In-Reply-To: <20241018162437.782c12c1@imammedo.users.ipa.redhat.com>
Hi Igor,
> From: Igor Mammedov <imammedo@redhat.com>
> Sent: Friday, October 18, 2024 3:25 PM
> To: Salil Mehta <salil.mehta@huawei.com>
> Cc: qemu-devel@nongnu.org; qemu-arm@nongnu.org; mst@redhat.com;
> maz@kernel.org; jean-philippe@linaro.org; Jonathan Cameron
> <jonathan.cameron@huawei.com>; lpieralisi@kernel.org;
> peter.maydell@linaro.org; richard.henderson@linaro.org;
> andrew.jones@linux.dev; david@redhat.com; philmd@linaro.org;
> eric.auger@redhat.com; will@kernel.org; ardb@kernel.org;
> oliver.upton@linux.dev; pbonzini@redhat.com; gshan@redhat.com;
> rafael@kernel.org; borntraeger@linux.ibm.com; alex.bennee@linaro.org;
> npiggin@gmail.com; harshpb@linux.ibm.com; linux@armlinux.org.uk;
> darren@os.amperecomputing.com; ilkka@os.amperecomputing.com;
> vishnu@os.amperecomputing.com; karl.heubaum@oracle.com;
> miguel.luis@oracle.com; salil.mehta@opnsrc.net; zhukeqian
> <zhukeqian1@huawei.com>; wangxiongfeng (C)
> <wangxiongfeng2@huawei.com>; wangyanan (Y)
> <wangyanan55@huawei.com>; jiakernel2@gmail.com;
> maobibo@loongson.cn; lixianglai@loongson.cn; shahuang@redhat.com;
> zhao1.liu@intel.com; Linuxarm <linuxarm@huawei.com>;
> gustavo.romero@linaro.org
> Subject: Re: [PATCH V1 3/4] hw/acpi: Reflect ACPI vCPU {present,enabled}
> states in ACPI _STA.{PRES,ENA} Bits
>
> On Mon, 14 Oct 2024 20:22:04 +0100
> Salil Mehta <salil.mehta@huawei.com> wrote:
>
> > Reflect the ACPI CPU hotplug `is_{present, enabled}` states in the
> > `_STA.PRES`
> > (presence) and `_STA.ENA` (enabled) bits when the guest kernel
> > evaluates the ACPI `_STA` method during initialization, as well as
> > when vCPUs are hot-plugged or hot-unplugged. The presence of
> unplugged
> > vCPUs may need to be deliberately
> > *simulated* at the ACPI level to maintain a *persistent* view of vCPUs
> > for the guest kernel.
>
> given questionable future of is_present/is_enabled fields, it probably
> premature to review this part.
Sure, let us discuss the pain points.
> The only thing, I have to say here is repeating spec/doc update patch
> describing how it should work should come 1st, so that we could compare
> this impl. with it.
From the user perspective, there should not be any change in how he
plug/unplugs the ARM vCPUs. This is a requirement, as we have to
assists folks who wants to migrate from x86 world to ARM world
seamlessly (without affecting performance parameters) and this
feature is one small part of that bigger effort.
> > Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
> > ---
> > hw/acpi/cpu.c | 26 ++++++++++++++++++++++----
> > 1 file changed, 22 insertions(+), 4 deletions(-)
> >
> > diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c index
> > 700aa855e9..23ea2b9c70 100644
> > --- a/hw/acpi/cpu.c
> > +++ b/hw/acpi/cpu.c
> > @@ -63,10 +63,11 @@ static uint64_t cpu_hotplug_rd(void *opaque,
> hwaddr addr, unsigned size)
> > cdev = &cpu_st->devs[cpu_st->selector];
> > switch (addr) {
> > case ACPI_CPU_FLAGS_OFFSET_RW: /* pack and return is_* fields */
> > - val |= cdev->cpu ? 1 : 0;
> > + val |= cdev->is_enabled ? 1 : 0;
> > val |= cdev->is_inserting ? 2 : 0;
> > val |= cdev->is_removing ? 4 : 0;
> > val |= cdev->fw_remove ? 16 : 0;
> > + val |= cdev->is_present ? 32 : 0;
> > trace_cpuhp_acpi_read_flags(cpu_st->selector, val);
> > break;
> > case ACPI_CPU_CMD_DATA_OFFSET_RW:
> > @@ -376,6 +377,7 @@ const VMStateDescription vmstate_cpu_hotplug =
> {
> > #define CPU_REMOVE_EVENT "CRMV"
> > #define CPU_EJECT_EVENT "CEJ0"
> > #define CPU_FW_EJECT_EVENT "CEJF"
> > +#define CPU_PRESENT "CPRS"
> >
> > void build_cpus_aml(Aml *table, MachineState *machine,
> CPUHotplugFeatures opts,
> > build_madt_cpu_fn build_madt_cpu, hwaddr
> > base_addr, @@ -436,7 +438,9 @@ void build_cpus_aml(Aml *table,
> MachineState *machine, CPUHotplugFeatures opts,
> > aml_append(field, aml_named_field(CPU_EJECT_EVENT, 1));
> > /* tell firmware to do device eject, write only */
> > aml_append(field, aml_named_field(CPU_FW_EJECT_EVENT, 1));
> > - aml_append(field, aml_reserved_field(3));
> > + /* 1 if present, read only */
> > + aml_append(field, aml_named_field(CPU_PRESENT, 1));
> > + aml_append(field, aml_reserved_field(2));
> > aml_append(field, aml_named_field(CPU_COMMAND, 8));
> > aml_append(cpu_ctrl_dev, field);
> >
> > @@ -466,6 +470,7 @@ void build_cpus_aml(Aml *table, MachineState
> *machine, CPUHotplugFeatures opts,
> > Aml *ctrl_lock = aml_name("%s.%s", cphp_res_path, CPU_LOCK);
> > Aml *cpu_selector = aml_name("%s.%s", cphp_res_path,
> CPU_SELECTOR);
> > Aml *is_enabled = aml_name("%s.%s", cphp_res_path,
> > CPU_ENABLED);
> > + Aml *is_present = aml_name("%s.%s", cphp_res_path,
> > + CPU_PRESENT);
> > Aml *cpu_cmd = aml_name("%s.%s", cphp_res_path,
> CPU_COMMAND);
> > Aml *cpu_data = aml_name("%s.%s", cphp_res_path, CPU_DATA);
> > Aml *ins_evt = aml_name("%s.%s", cphp_res_path,
> > CPU_INSERT_EVENT); @@ -494,13 +499,26 @@ void build_cpus_aml(Aml
> *table, MachineState *machine, CPUHotplugFeatures opts,
> > {
> > Aml *idx = aml_arg(0);
> > Aml *sta = aml_local(0);
> > + Aml *ifctx2;
> > + Aml *else_ctx;
> >
> > aml_append(method, aml_acquire(ctrl_lock, 0xFFFF));
> > aml_append(method, aml_store(idx, cpu_selector));
> > aml_append(method, aml_store(zero, sta));
> > - ifctx = aml_if(aml_equal(is_enabled, one));
> > + ifctx = aml_if(aml_equal(is_present, one));
> > {
> > - aml_append(ifctx, aml_store(aml_int(0xF), sta));
> > + ifctx2 = aml_if(aml_equal(is_enabled, one));
> > + {
> > + /* cpu is present and enabled */
> > + aml_append(ifctx2, aml_store(aml_int(0xF), sta));
> > + }
> > + aml_append(ifctx, ifctx2);
> > + else_ctx = aml_else();
> > + {
> > + /* cpu is present but disabled */
> > + aml_append(else_ctx, aml_store(aml_int(0xD), sta));
> > + }
> > + aml_append(ifctx, else_ctx);
> > }
> > aml_append(method, ifctx);
> > aml_append(method, aml_release(ctrl_lock));
>
next prev parent reply other threads:[~2024-10-22 23:58 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-14 19:22 [PATCH V1 0/4] Arch agnostic ACPI changes to support vCPU Hotplug (on Archs like ARM) Salil Mehta via
2024-10-14 19:22 ` [PATCH V1 1/4] hw/acpi: Initialize ACPI Hotplug CPU Status with Support for vCPU `Persistence` Salil Mehta via
2024-10-16 21:01 ` Gustavo Romero
2024-10-21 20:50 ` Salil Mehta
2024-10-17 5:27 ` Gavin Shan
2024-10-21 21:19 ` Salil Mehta
2024-10-17 5:35 ` Gavin Shan
2024-10-17 20:25 ` Gustavo Romero
2024-10-21 21:22 ` Salil Mehta
2024-10-18 14:11 ` Igor Mammedov
2024-10-21 21:50 ` Salil Mehta
2024-10-25 13:52 ` Igor Mammedov
2024-11-01 10:53 ` Salil Mehta via
2024-11-04 11:43 ` Salil Mehta via
2024-10-14 19:22 ` [PATCH V1 2/4] hw/acpi: Update ACPI CPU Status `is_{present, enabled}` during vCPU hot(un)plug Salil Mehta via
2024-10-18 14:18 ` Igor Mammedov
2024-10-22 23:02 ` Salil Mehta via
2024-10-14 19:22 ` [PATCH V1 3/4] hw/acpi: Reflect ACPI vCPU {present, enabled} states in ACPI _STA.{PRES, ENA} Bits Salil Mehta via
2024-10-18 5:12 ` [PATCH V1 3/4] hw/acpi: Reflect ACPI vCPU {present,enabled} states in ACPI _STA.{PRES,ENA} Bits Zhao Liu
2024-10-18 14:19 ` Igor Mammedov
2024-10-22 23:50 ` Salil Mehta via
2024-10-22 23:45 ` Salil Mehta via
2024-10-18 14:24 ` Igor Mammedov
2024-10-22 23:57 ` Salil Mehta via [this message]
2024-10-21 2:09 ` Gustavo Romero
2024-10-23 1:01 ` Salil Mehta via
2024-10-14 19:22 ` [PATCH V1 4/4] hw/acpi: Populate vCPU Hotplug VMSD to migrate `is_{present, enabled}` states Salil Mehta via
2024-10-18 14:31 ` [PATCH V1 4/4] hw/acpi: Populate vCPU Hotplug VMSD to migrate `is_{present,enabled}` states Igor Mammedov
2024-10-22 23:22 ` Salil Mehta via
2024-10-15 3:30 ` [PATCH V1 0/4] Arch agnostic ACPI changes to support vCPU Hotplug (on Archs like ARM) maobibo
2024-10-15 14:31 ` Salil Mehta via
2024-10-16 6:00 ` maobibo
2024-10-15 18:41 ` Miguel Luis
2024-10-18 17:57 ` Gustavo Romero
2024-10-21 8:04 ` Miguel Luis
2024-10-22 12:32 ` Gustavo Romero
2024-10-18 14:46 ` Igor Mammedov
2024-10-21 2:33 ` Gustavo Romero
2024-10-23 1:50 ` 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=a8f41af5e450446e8dd68ebf9b9305a6@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=gustavo.romero@linaro.org \
--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).