From: Igor Mammedov <imammedo@redhat.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: "Michael S . Tsirkin" <mst@redhat.com>,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
"Shiju Jose" <shiju.jose@huawei.com>,
qemu-arm@nongnu.org, qemu-devel@nongnu.org,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Ani Sinha" <anisinha@redhat.com>,
"Dongjiu Geng" <gengdongjiu1@gmail.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Shannon Zhao" <shannon.zhaosl@gmail.com>,
"Yanan Wang" <wangyanan55@huawei.com>,
"Zhao Liu" <zhao1.liu@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 05/14] acpi/generic_event_device: add logic to detect if HEST addr is available
Date: Mon, 3 Feb 2025 15:56:17 +0100 [thread overview]
Message-ID: <20250203155617.50d25320@imammedo.users.ipa.redhat.com> (raw)
In-Reply-To: <0fb474d83bcb4464cf8b23822044688bdc3fd945.1738345063.git.mchehab+huawei@kernel.org>
On Fri, 31 Jan 2025 18:42:46 +0100
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> Create a new property (x-has-hest-addr) and use it to detect if
> the GHES table offsets can be calculated from the HEST address
> (qemu 10.0 and upper) or via the legacy way via an offset obtained
> from the hardware_errors firmware file.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
> hw/acpi/generic_event_device.c | 1 +
> hw/acpi/ghes.c | 17 ++++++-----------
> hw/arm/virt-acpi-build.c | 32 ++++++++++++++++++++++++++++----
> hw/core/machine.c | 2 ++
> include/hw/acpi/ghes.h | 3 ++-
> 5 files changed, 39 insertions(+), 16 deletions(-)
>
> diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
> index 5346cae573b7..14d8513a5440 100644
> --- a/hw/acpi/generic_event_device.c
> +++ b/hw/acpi/generic_event_device.c
> @@ -318,6 +318,7 @@ static void acpi_ged_send_event(AcpiDeviceIf *adev, AcpiEventStatusBits ev)
>
> static const Property acpi_ged_properties[] = {
> DEFINE_PROP_UINT32("ged-event", AcpiGedState, ged_event_bitmap, 0),
> + DEFINE_PROP_BOOL("x-has-hest-addr", AcpiGedState, ghes_state.use_hest_addr, false),
> };
>
> static const VMStateDescription vmstate_memhp_state = {
> diff --git a/hw/acpi/ghes.c b/hw/acpi/ghes.c
> index 8f284fd191a6..a91dcd777433 100644
> --- a/hw/acpi/ghes.c
> +++ b/hw/acpi/ghes.c
> @@ -359,7 +359,8 @@ static void build_ghes_v2_entry(GArray *table_data,
> }
>
> /* Build Hardware Error Source Table */
> -void acpi_build_hest(GArray *table_data, GArray *hardware_errors,
> +void acpi_build_hest(AcpiGhesState *ags, GArray *table_data,
> + GArray *hardware_errors,
> BIOSLinker *linker,
> const AcpiNotificationSourceId *notif_source,
> int num_sources,
> @@ -369,14 +370,6 @@ void acpi_build_hest(GArray *table_data, GArray *hardware_errors,
> .oem_id = oem_id, .oem_table_id = oem_table_id };
> uint32_t hest_offset;
> int i;
> - AcpiGedState *acpi_ged_state;
> - AcpiGhesState *ags = NULL;
> -
> - acpi_ged_state = ACPI_GED(object_resolve_path_type("", TYPE_ACPI_GED,
> - NULL));
> - if (acpi_ged_state) {
> - ags = &acpi_ged_state->ghes_state;
> - }
hmh, can we move this once within series to the place where it should end up at,
instead of rewriting just added code over again,
somewhere at the being of series (maybe as separate patch)?
> hest_offset = table_data->len;
>
> @@ -415,8 +408,10 @@ void acpi_ghes_add_fw_cfg(AcpiGhesState *ags, FWCfgState *s,
> fw_cfg_add_file_callback(s, ACPI_HW_ERROR_ADDR_FW_CFG_FILE, NULL, NULL,
> NULL, &(ags->hw_error_le), sizeof(ags->hw_error_le), false);
>
> - fw_cfg_add_file_callback(s, ACPI_HEST_ADDR_FW_CFG_FILE, NULL, NULL,
> - NULL, &(ags->hest_addr_le), sizeof(ags->hest_addr_le), false);
> + if (ags->use_hest_addr) {
> + fw_cfg_add_file_callback(s, ACPI_HEST_ADDR_FW_CFG_FILE, NULL, NULL,
> + NULL, &(ags->hest_addr_le), sizeof(ags->hest_addr_le), false);
> + }
the same as comment in 3/14, please no flipping back and forth which might
break bisection. Also this hunk looks misplaced and should be a part of 3/14
and do not forget about ACPI_HW_ERROR_ADDR_FW_CFG_FILE, that should be excluded
when use_hest_addr == TRUE
I see that 6/14 does that, but order makes it
>
> ags->present = true;
> }
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 3d411787fc37..9de51105a513 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -897,6 +897,10 @@ static const AcpiNotificationSourceId hest_ghes_notify[] = {
> { ACPI_HEST_SRC_ID_SYNC, ACPI_GHES_NOTIFY_SEA },
> };
>
> +static const AcpiNotificationSourceId hest_ghes_notify_9_2[] = {
> + { ACPI_HEST_SRC_ID_SYNC, ACPI_GHES_NOTIFY_SEA },
> +};
> +
> static
> void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
> {
> @@ -950,10 +954,30 @@ void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
> build_dbg2(tables_blob, tables->linker, vms);
>
> if (vms->ras) {
> - acpi_add_table(table_offsets, tables_blob);
> - acpi_build_hest(tables_blob, tables->hardware_errors, tables->linker,
> - hest_ghes_notify, ARRAY_SIZE(hest_ghes_notify),
> - vms->oem_id, vms->oem_table_id);
> + static const AcpiNotificationSourceId *notify;
> + AcpiGedState *acpi_ged_state;
> + unsigned int notify_sz;
> + AcpiGhesState *ags;
> +
> + acpi_ged_state = ACPI_GED(object_resolve_path_type("", TYPE_ACPI_GED,
> + NULL));
> + if (acpi_ged_state) {
> + ags = &acpi_ged_state->ghes_state;
> +
> + acpi_add_table(table_offsets, tables_blob);
> +
> + if (!ags->use_hest_addr) {
> + notify = hest_ghes_notify_9_2;
> + notify_sz = ARRAY_SIZE(hest_ghes_notify_9_2);
all 9.2 compat hunks look misplaced,
they have no relation to using HEST addr at all,
they belong to the patches that introduce new error type
i.e. where hest_ghes_notify mutates to 2 entry array.
> + } else {
> + notify = hest_ghes_notify;
> + notify_sz = ARRAY_SIZE(hest_ghes_notify);
> + }
> +
> + acpi_build_hest(ags, tables_blob, tables->hardware_errors,
> + tables->linker, notify, notify_sz,
> + vms->oem_id, vms->oem_table_id);
> + }
> }
>
> if (ms->numa_state->num_nodes > 0) {
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index c23b39949649..0d0cde481954 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -34,10 +34,12 @@
> #include "hw/virtio/virtio-pci.h"
> #include "hw/virtio/virtio-net.h"
> #include "hw/virtio/virtio-iommu.h"
> +#include "hw/acpi/generic_event_device.h"
> #include "audio/audio.h"
>
> GlobalProperty hw_compat_9_2[] = {
> {"arm-cpu", "backcompat-pauth-default-use-qarma5", "true"},
> + { TYPE_ACPI_GED, "x-has-hest-addr", "false" },
> };
> const size_t hw_compat_9_2_len = G_N_ELEMENTS(hw_compat_9_2);
>
> diff --git a/include/hw/acpi/ghes.h b/include/hw/acpi/ghes.h
> index 6c2e57af0456..bfc8fd851648 100644
> --- a/include/hw/acpi/ghes.h
> +++ b/include/hw/acpi/ghes.h
> @@ -76,7 +76,8 @@ typedef struct AcpiNotificationSourceId {
> enum AcpiGhesNotifyType notify;
> } AcpiNotificationSourceId;
>
> -void acpi_build_hest(GArray *table_data, GArray *hardware_errors,
> +void acpi_build_hest(AcpiGhesState *ags, GArray *table_data,
> + GArray *hardware_errors,
> BIOSLinker *linker,
> const AcpiNotificationSourceId * const notif_source,
> int num_sources,
next prev parent reply other threads:[~2025-02-03 14:57 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-31 17:42 [PATCH v3 00/14] Change ghes to use HEST-based offsets and add support for error inject Mauro Carvalho Chehab
2025-01-31 17:42 ` [PATCH v3 01/14] acpi/ghes: Prepare to support multiple sources on ghes Mauro Carvalho Chehab
2025-01-31 17:42 ` [PATCH v3 02/14] acpi/ghes: add a firmware file with HEST address Mauro Carvalho Chehab
2025-02-03 13:41 ` Igor Mammedov
2025-01-31 17:42 ` [PATCH v3 03/14] acpi/ghes: Use HEST table offsets when preparing GHES records Mauro Carvalho Chehab
2025-02-03 10:42 ` Jonathan Cameron via
2025-02-03 14:34 ` Igor Mammedov
2025-02-21 6:02 ` Mauro Carvalho Chehab
2025-02-25 9:43 ` Igor Mammedov
2025-02-26 16:14 ` Mauro Carvalho Chehab
2025-02-27 9:22 ` Igor Mammedov
2025-02-27 10:11 ` Mauro Carvalho Chehab
2025-01-31 17:42 ` [PATCH v3 04/14] acpi/generic_event_device: Update GHES migration to cover hest addr Mauro Carvalho Chehab
2025-01-31 17:42 ` [PATCH v3 05/14] acpi/generic_event_device: add logic to detect if HEST addr is available Mauro Carvalho Chehab
2025-02-03 14:56 ` Igor Mammedov [this message]
2025-01-31 17:42 ` [PATCH v3 06/14] acpi/ghes: only set hw_error_le or hest_addr_le Mauro Carvalho Chehab
2025-02-03 10:48 ` Jonathan Cameron via
2025-01-31 17:42 ` [PATCH v3 07/14] acpi/ghes: add a notifier to notify when error data is ready Mauro Carvalho Chehab
2025-01-31 17:42 ` [PATCH v3 08/14] acpi/ghes: Cleanup the code which gets ghes ged state Mauro Carvalho Chehab
2025-02-03 10:51 ` Jonathan Cameron via
2025-01-31 17:42 ` [PATCH v3 09/14] acpi/generic_event_device: add an APEI error device Mauro Carvalho Chehab
2025-01-31 17:42 ` [PATCH v3 10/14] tests/acpi: virt: allow acpi table changes for a new table: HEST Mauro Carvalho Chehab
2025-01-31 17:42 ` [PATCH v3 11/14] arm/virt: Wire up a GED error device for ACPI / GHES Mauro Carvalho Chehab
2025-01-31 17:42 ` [PATCH v3 12/14] tests/acpi: virt: add a HEST table to aarch64 virt and update DSDT Mauro Carvalho Chehab
2025-02-03 10:53 ` Jonathan Cameron via
2025-01-31 17:42 ` [PATCH v3 13/14] qapi/acpi-hest: add an interface to do generic CPER error injection Mauro Carvalho Chehab
2025-02-05 8:12 ` Markus Armbruster
2025-01-31 17:42 ` [PATCH v3 14/14] scripts/ghes_inject: add a script to generate GHES error inject Mauro Carvalho Chehab
2025-02-03 10:56 ` Jonathan Cameron via
2025-02-05 8:16 ` Markus Armbruster
2025-02-21 4:57 ` Mauro Carvalho Chehab
2025-02-21 5:50 ` Markus Armbruster
2025-02-03 11:09 ` [PATCH v3 00/14] Change ghes to use HEST-based offsets and add support for " Jonathan Cameron via
2025-02-03 15:22 ` Igor Mammedov
2025-02-21 6:38 ` Mauro Carvalho Chehab
2025-02-21 10:21 ` Jonathan Cameron via
2025-02-21 12:23 ` Mauro Carvalho Chehab
2025-02-21 15:05 ` Mauro Carvalho Chehab
2025-02-25 10:01 ` Igor Mammedov
2025-02-26 9:56 ` Mauro Carvalho Chehab
2025-02-26 11:23 ` Mauro Carvalho Chehab
2025-02-26 11:31 ` Mauro Carvalho Chehab
2025-02-26 12:29 ` Igor Mammedov
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=20250203155617.50d25320@imammedo.users.ipa.redhat.com \
--to=imammedo@redhat.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=anisinha@redhat.com \
--cc=eduardo@habkost.net \
--cc=gengdongjiu1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=mchehab+huawei@kernel.org \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shannon.zhaosl@gmail.com \
--cc=shiju.jose@huawei.com \
--cc=wangyanan55@huawei.com \
--cc=zhao1.liu@intel.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).