From: Bernhard Beschow <shentey@gmail.com>
To: qemu-devel@nongnu.org
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Aurelien Jarno" <aurelien@aurel32.net>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Sergio Lopez" <slp@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Igor Mammedov" <imammedo@redhat.com>,
"Ani Sinha" <anisinha@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Bernhard Beschow" <shentey@gmail.com>
Subject: [PATCH v2 2/8] hw/acpi/cpu: Have build_cpus_aml() take a build_madt_cpu_fn callback
Date: Fri, 8 Sep 2023 10:42:28 +0200 [thread overview]
Message-ID: <20230908084234.17642-3-shentey@gmail.com> (raw)
In-Reply-To: <20230908084234.17642-1-shentey@gmail.com>
build_cpus_aml() is architecture independent but needs to create architecture-
specific CPU AML. So far this was achieved by using a virtual method from
TYPE_ACPI_DEVICE_IF. However, build_cpus_aml() would resolve this interface from
global (!) state. This makes it quite incomprehensible where this interface
comes from (TYPE_PIIX4_PM?, TYPE_ICH9_LPC_DEVICE?, TYPE_ACPI_GED_X86?) an can
lead to crashes when the generic code is ported to new architectures.
So far, build_cpus_aml() is only called in architecture-specific code -- and
only in x86. We can therefore simply pass pc_madt_cpu_entry() as callback to
build_cpus_aml(). This is the same callback that would be used through
TYPE_ACPI_DEVICE_IF.
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
include/hw/acpi/cpu.h | 6 +++++-
hw/acpi/cpu.c | 8 ++------
hw/i386/acpi-build.c | 4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/hw/acpi/cpu.h b/include/hw/acpi/cpu.h
index 999caaf510..bc901660fb 100644
--- a/include/hw/acpi/cpu.h
+++ b/include/hw/acpi/cpu.h
@@ -15,6 +15,7 @@
#include "hw/qdev-core.h"
#include "hw/acpi/acpi.h"
#include "hw/acpi/aml-build.h"
+#include "hw/boards.h"
#include "hw/hotplug.h"
typedef struct AcpiCpuStatus {
@@ -55,8 +56,11 @@ typedef struct CPUHotplugFeatures {
const char *smi_path;
} CPUHotplugFeatures;
+typedef void (*build_madt_cpu_fn)(int uid, const CPUArchIdList *apic_ids,
+ GArray *entry, bool force_enabled);
+
void build_cpus_aml(Aml *table, MachineState *machine, CPUHotplugFeatures opts,
- hwaddr io_base,
+ build_madt_cpu_fn build_madt_cpu, hwaddr io_base,
const char *res_root,
const char *event_handler_method);
diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c
index 19c154d78f..65a3202d3f 100644
--- a/hw/acpi/cpu.c
+++ b/hw/acpi/cpu.c
@@ -338,7 +338,7 @@ const VMStateDescription vmstate_cpu_hotplug = {
#define CPU_FW_EJECT_EVENT "CEJF"
void build_cpus_aml(Aml *table, MachineState *machine, CPUHotplugFeatures opts,
- hwaddr io_base,
+ build_madt_cpu_fn build_madt_cpu, hwaddr io_base,
const char *res_root,
const char *event_handler_method)
{
@@ -353,8 +353,6 @@ void build_cpus_aml(Aml *table, MachineState *machine, CPUHotplugFeatures opts,
MachineClass *mc = MACHINE_GET_CLASS(machine);
const CPUArchIdList *arch_ids = mc->possible_cpu_arch_ids(machine);
char *cphp_res_path = g_strdup_printf("%s." CPUHP_RES_DEVICE, res_root);
- Object *obj = object_resolve_path_type("", TYPE_ACPI_DEVICE_IF, NULL);
- AcpiDeviceIfClass *adevc = ACPI_DEVICE_IF_GET_CLASS(obj);
cpu_ctrl_dev = aml_device("%s", cphp_res_path);
{
@@ -664,9 +662,7 @@ void build_cpus_aml(Aml *table, MachineState *machine, CPUHotplugFeatures opts,
aml_append(dev, method);
/* build _MAT object */
- assert(adevc && adevc->madt_cpu);
- adevc->madt_cpu(i, arch_ids, madt_buf,
- true); /* set enabled flag */
+ build_madt_cpu(i, arch_ids, madt_buf, true); /* set enabled flag */
aml_append(dev, aml_name_decl("_MAT",
aml_buffer(madt_buf->len, (uint8_t *)madt_buf->data)));
g_array_free(madt_buf, true);
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 09586b8d9b..c8ac665d36 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1549,8 +1549,8 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
.smi_path = pm->smi_on_cpuhp ? "\\_SB.PCI0.SMI0.SMIC" : NULL,
.fw_unplugs_cpu = pm->smi_on_cpu_unplug,
};
- build_cpus_aml(dsdt, machine, opts, pm->cpu_hp_io_base,
- "\\_SB.PCI0", "\\_GPE._E02");
+ build_cpus_aml(dsdt, machine, opts, pc_madt_cpu_entry,
+ pm->cpu_hp_io_base, "\\_SB.PCI0", "\\_GPE._E02");
}
if (pcms->memhp_io_base && nr_mem) {
--
2.42.0
next prev parent reply other threads:[~2023-09-08 8:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-08 8:42 [PATCH v2 0/8] ACPI: X86 AML generation and GPE tracing cleanup Bernhard Beschow
2023-09-08 8:42 ` [PATCH v2 1/8] hw/i386/acpi-build: Use pc_madt_cpu_entry() directly Bernhard Beschow
2023-09-08 8:42 ` Bernhard Beschow [this message]
2023-09-08 8:42 ` [PATCH v2 3/8] hw/acpi/acpi_dev_interface: Remove now unused madt_cpu virtual method Bernhard Beschow
2023-09-08 8:42 ` [PATCH v2 4/8] hw/acpi/acpi_dev_interface: Remove now unused #include "hw/boards.h" Bernhard Beschow
2023-09-08 8:42 ` [PATCH v2 5/8] hw/i386: Remove now redundant TYPE_ACPI_GED_X86 Bernhard Beschow
2023-09-08 8:42 ` [PATCH v2 6/8] hw/i386/acpi-build: Determine SMI command port just once Bernhard Beschow
2023-09-08 8:42 ` [PATCH v2 7/8] hw/acpi: Trace GPE access in all device models, not just PIIX4 Bernhard Beschow
2023-09-08 8:42 ` [PATCH v2 8/8] hw/acpi/core: Trace enable and status registers of GPE separately Bernhard Beschow
2023-09-19 19:47 ` [PATCH v2 0/8] ACPI: X86 AML generation and GPE tracing cleanup Bernhard Beschow
2023-09-20 2:42 ` Michael S. Tsirkin
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=20230908084234.17642-3-shentey@gmail.com \
--to=shentey@gmail.com \
--cc=anisinha@redhat.com \
--cc=aurelien@aurel32.net \
--cc=eduardo@habkost.net \
--cc=imammedo@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=slp@redhat.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).