From: Salil Mehta <salil.mehta@huawei.com>
To: Gustavo Romero <gustavo.romero@linaro.org>,
"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>,
"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>
Subject: RE: [PATCH V1 3/4] hw/acpi: Reflect ACPI vCPU {present,enabled} states in ACPI _STA.{PRES,ENA} Bits
Date: Wed, 23 Oct 2024 01:01:24 +0000 [thread overview]
Message-ID: <f3b24abb74604f07aa76bead91277d6d@huawei.com> (raw)
In-Reply-To: <700f6b4b-e609-42fe-afaf-e9ea62a049e1@linaro.org>
Hi Gustavo,
> From: Gustavo Romero <gustavo.romero@linaro.org>
> Sent: Monday, October 21, 2024 3:10 AM
> To: Salil Mehta <salil.mehta@huawei.com>; qemu-devel@nongnu.org;
> qemu-arm@nongnu.org; mst@redhat.com
>
> Hi Salil,
>
> On 10/14/24 16:22, Salil Mehta 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.
> >
> > 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));
>
> Here, the return value for _STA method is set to reflect the state of
> CPU_PRESENT and CPU_ENABLED fields. I can't see these two fields being
> mapped to AcpiCpuStatus.{is_present,is_enabled}. They look to be mapped
> to the MMIO region (base_addr), which doesn't mapped to AcpiCpuStatus
> afaics. So where CPU_PRESENT and CPU_ENABLED are set and where
> exactly they reside?
You don’t set _STA field from guest for CPUs. We only fetch values being
reflected by the VMM. In general, ACPI _STA method is for fetching status
of a device. Please check below:
https://uefi.org/specs/ACPI/6.5/06_Device_Configuration.html?highlight=_sta#sta-device-status
We are banking on below status bits:
Bit [0] - Set if the device is present.
Bit [1] - Set if the device is enabled and decoding its resources.
Hence, AcpiCpuStatus::(is_present, is_enabled} are set in the VMM
and their status is shared to the guest kernel when the ACPI _STA
method is evaluated by the OSPM.
Patch 3/4: https://lore.kernel.org/qemu-devel/20241014192205.253479-4-salil.mehta@huawei.com/
#HUNK
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];---------> check this code excerpt
switch (addr) {
case ACPI_CPU_FLAGS_OFFSET_RW: /* pack and return is_* fields */
- val |= cdev->cpu ? 1 : 0;
+ val |= cdev->is_enabled ? 1 : 0;---------------> this change
val |= cdev->is_inserting ? 2 : 0;
val |= cdev->is_removing ? 4 : 0;
val |= cdev->fw_remove ? 16 : 0;
+ val |= cdev->is_present ? 32 : 0;-------------> and this change
trace_cpuhp_acpi_read_flags(cpu_st->selector, val);
break;
case ACPI_CPU_CMD_DATA_OFFSET_RW:
Thanks
>
>
> Cheers,
> Gustavo
>
> > + }
> > + aml_append(ifctx, else_ctx);
> > }
> > aml_append(method, ifctx);
> > aml_append(method, aml_release(ctrl_lock));
WARNING: multiple messages have this Message-ID (diff)
From: Salil Mehta via <qemu-devel@nongnu.org>
To: Gustavo Romero <gustavo.romero@linaro.org>,
"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>,
"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>
Subject: RE: [PATCH V1 3/4] hw/acpi: Reflect ACPI vCPU {present,enabled} states in ACPI _STA.{PRES,ENA} Bits
Date: Wed, 23 Oct 2024 01:01:24 +0000 [thread overview]
Message-ID: <f3b24abb74604f07aa76bead91277d6d@huawei.com> (raw)
In-Reply-To: <700f6b4b-e609-42fe-afaf-e9ea62a049e1@linaro.org>
Hi Gustavo,
> From: Gustavo Romero <gustavo.romero@linaro.org>
> Sent: Monday, October 21, 2024 3:10 AM
> To: Salil Mehta <salil.mehta@huawei.com>; qemu-devel@nongnu.org;
> qemu-arm@nongnu.org; mst@redhat.com
>
> Hi Salil,
>
> On 10/14/24 16:22, Salil Mehta 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.
> >
> > 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));
>
> Here, the return value for _STA method is set to reflect the state of
> CPU_PRESENT and CPU_ENABLED fields. I can't see these two fields being
> mapped to AcpiCpuStatus.{is_present,is_enabled}. They look to be mapped
> to the MMIO region (base_addr), which doesn't mapped to AcpiCpuStatus
> afaics. So where CPU_PRESENT and CPU_ENABLED are set and where
> exactly they reside?
You don’t set _STA field from guest for CPUs. We only fetch values being
reflected by the VMM. In general, ACPI _STA method is for fetching status
of a device. Please check below:
https://uefi.org/specs/ACPI/6.5/06_Device_Configuration.html?highlight=_sta#sta-device-status
We are banking on below status bits:
Bit [0] - Set if the device is present.
Bit [1] - Set if the device is enabled and decoding its resources.
Hence, AcpiCpuStatus::(is_present, is_enabled} are set in the VMM
and their status is shared to the guest kernel when the ACPI _STA
method is evaluated by the OSPM.
Patch 3/4: https://lore.kernel.org/qemu-devel/20241014192205.253479-4-salil.mehta@huawei.com/
#HUNK
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];---------> check this code excerpt
switch (addr) {
case ACPI_CPU_FLAGS_OFFSET_RW: /* pack and return is_* fields */
- val |= cdev->cpu ? 1 : 0;
+ val |= cdev->is_enabled ? 1 : 0;---------------> this change
val |= cdev->is_inserting ? 2 : 0;
val |= cdev->is_removing ? 4 : 0;
val |= cdev->fw_remove ? 16 : 0;
+ val |= cdev->is_present ? 32 : 0;-------------> and this change
trace_cpuhp_acpi_read_flags(cpu_st->selector, val);
break;
case ACPI_CPU_CMD_DATA_OFFSET_RW:
Thanks
>
>
> Cheers,
> Gustavo
>
> > + }
> > + aml_append(ifctx, else_ctx);
> > }
> > aml_append(method, ifctx);
> > aml_append(method, aml_release(ctrl_lock));
next prev parent reply other threads:[~2024-10-23 1:01 UTC|newest]
Thread overview: 54+ 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
2024-10-14 19:22 ` 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
2024-10-14 19:22 ` 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
2024-11-01 10:53 ` Salil Mehta via
2024-11-04 11:43 ` Salil Mehta
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
2024-10-14 19:22 ` Salil Mehta via
2024-10-18 14:18 ` Igor Mammedov
2024-10-22 23:02 ` Salil Mehta
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
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
2024-10-22 23:50 ` Salil Mehta via
2024-10-22 23:45 ` Salil Mehta
2024-10-22 23:45 ` Salil Mehta via
2024-10-18 14:24 ` Igor Mammedov
2024-10-22 23:57 ` Salil Mehta
2024-10-22 23:57 ` Salil Mehta via
2024-10-21 2:09 ` Gustavo Romero
2024-10-23 1:01 ` Salil Mehta [this message]
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
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
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
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
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=f3b24abb74604f07aa76bead91277d6d@huawei.com \
--to=salil.mehta@huawei.com \
--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=qemu-devel@nongnu.org \
--cc=rafael@kernel.org \
--cc=richard.henderson@linaro.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.