From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Igor Mammedov <imammedo@redhat.com>,
Shiju Jose <shiju.jose@huawei.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Ani Sinha <anisinha@redhat.com>,
Dongjiu Geng <gengdongjiu1@gmail.com>,
Peter Maydell <peter.maydell@linaro.org>,
Shannon Zhao <shannon.zhaosl@gmail.com>,
<linux-kernel@vger.kernel.org>, <qemu-arm@nongnu.org>,
<qemu-devel@nongnu.org>
Subject: Re: [PATCH 1/6] acpi/ghes: Prepare to support multiple sources on ghes
Date: Wed, 20 Nov 2024 14:29:31 +0000 [thread overview]
Message-ID: <20241120142931.00006b63@huawei.com> (raw)
In-Reply-To: <3f6b7e8499bf5911de9b1533e4b2a4addc207536.1731486604.git.mchehab+huawei@kernel.org>
On Wed, 13 Nov 2024 09:36:58 +0100
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> The current code is actually dependent on having just one
> error structure with a single source.
Trivial: Very short line wrap of the description. Maybe more
than 60 chars?
>
> As the number of sources should be arch-dependent, as it
> will depend on what kind of synchronous/assynchronous
> notifications will exist, change the logic to dynamically
> build the table.
>
> Yet, for a proper support, we need to get the number of
> sources by reading the number from the HEST table. However,
> bios currently doesn't store a pointer to it.
>
> For now just change the logic at table build time, while
> enforcing that it will behave like before with a single
> source ID.
>
> A future patch will add a HEST table bios pointer and
> change the logic at acpi_ghes_record_errors() to
> dynamically use the new size.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Took a fresh look. One trivial comment.
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index e059317b002e..40f66792570c 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -889,6 +889,10 @@ static void acpi_align_size(GArray *blob, unsigned align)
> g_array_set_size(blob, ROUND_UP(acpi_data_len(blob), align));
> }
>
> +static const AcpiNotificationSourceId hest_ghes_notify[] = {
> + {ACPI_HEST_SRC_ID_SYNC, ACPI_GHES_NOTIFY_SEA},
{ ACPI_HEST_SRC_ID_SYNC, ACPI_GHES_NOTIFY_SEA },
seems to be local style.
> +};
> +
> static
> void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
> {
> @@ -944,6 +948,7 @@ void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
> 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);
> }
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Igor Mammedov <imammedo@redhat.com>,
Shiju Jose <shiju.jose@huawei.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Ani Sinha <anisinha@redhat.com>,
Dongjiu Geng <gengdongjiu1@gmail.com>,
Peter Maydell <peter.maydell@linaro.org>,
Shannon Zhao <shannon.zhaosl@gmail.com>,
<linux-kernel@vger.kernel.org>, <qemu-arm@nongnu.org>,
<qemu-devel@nongnu.org>
Subject: Re: [PATCH 1/6] acpi/ghes: Prepare to support multiple sources on ghes
Date: Wed, 20 Nov 2024 14:29:31 +0000 [thread overview]
Message-ID: <20241120142931.00006b63@huawei.com> (raw)
In-Reply-To: <3f6b7e8499bf5911de9b1533e4b2a4addc207536.1731486604.git.mchehab+huawei@kernel.org>
On Wed, 13 Nov 2024 09:36:58 +0100
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> The current code is actually dependent on having just one
> error structure with a single source.
Trivial: Very short line wrap of the description. Maybe more
than 60 chars?
>
> As the number of sources should be arch-dependent, as it
> will depend on what kind of synchronous/assynchronous
> notifications will exist, change the logic to dynamically
> build the table.
>
> Yet, for a proper support, we need to get the number of
> sources by reading the number from the HEST table. However,
> bios currently doesn't store a pointer to it.
>
> For now just change the logic at table build time, while
> enforcing that it will behave like before with a single
> source ID.
>
> A future patch will add a HEST table bios pointer and
> change the logic at acpi_ghes_record_errors() to
> dynamically use the new size.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Took a fresh look. One trivial comment.
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index e059317b002e..40f66792570c 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -889,6 +889,10 @@ static void acpi_align_size(GArray *blob, unsigned align)
> g_array_set_size(blob, ROUND_UP(acpi_data_len(blob), align));
> }
>
> +static const AcpiNotificationSourceId hest_ghes_notify[] = {
> + {ACPI_HEST_SRC_ID_SYNC, ACPI_GHES_NOTIFY_SEA},
{ ACPI_HEST_SRC_ID_SYNC, ACPI_GHES_NOTIFY_SEA },
seems to be local style.
> +};
> +
> static
> void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
> {
> @@ -944,6 +948,7 @@ void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
> 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);
> }
next prev parent reply other threads:[~2024-11-20 14:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-13 8:36 [PATCH 0/6] Change ghes driver to use HEST-based offsets Mauro Carvalho Chehab
2024-11-13 8:36 ` [PATCH 1/6] acpi/ghes: Prepare to support multiple sources on ghes Mauro Carvalho Chehab
2024-11-20 14:29 ` Jonathan Cameron [this message]
2024-11-20 14:29 ` Jonathan Cameron via
2024-11-13 8:36 ` [PATCH 2/6] acpi/ghes: add a firmware file with HEST address Mauro Carvalho Chehab
2024-11-20 14:32 ` Jonathan Cameron via
2024-11-20 14:32 ` Jonathan Cameron
2024-11-20 14:32 ` Jonathan Cameron via
2024-11-13 8:37 ` [PATCH 3/6] acpi/ghes: rename the function which gets hw error offsets Mauro Carvalho Chehab
2024-11-20 14:33 ` Jonathan Cameron
2024-11-20 14:33 ` Jonathan Cameron via
2024-11-22 9:32 ` Mauro Carvalho Chehab
2024-11-13 8:37 ` [PATCH 4/6] acpi/ghes: Use HEST table offsets when preparing GHES records Mauro Carvalho Chehab
2024-11-20 14:59 ` Jonathan Cameron via
2024-11-20 14:59 ` Jonathan Cameron
2024-11-20 14:59 ` Jonathan Cameron via
2024-11-22 10:37 ` Mauro Carvalho Chehab
2024-11-25 11:31 ` Jonathan Cameron
2024-11-25 11:31 ` Jonathan Cameron via
2024-11-13 8:37 ` [PATCH 5/6] acpi/generic_event_device: Update GHES migration to cover hest addr Mauro Carvalho Chehab
2024-11-20 15:01 ` Jonathan Cameron via
2024-11-20 15:01 ` Jonathan Cameron
2024-11-22 10:40 ` Mauro Carvalho Chehab
2024-11-13 8:37 ` [PATCH 6/6] acpi/generic_event_device: add logic to detect if HEST addr is available Mauro Carvalho Chehab
2024-11-20 15:09 ` Jonathan Cameron via
2024-11-20 15:09 ` Jonathan Cameron
2024-11-20 15:09 ` Jonathan Cameron 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=20241120142931.00006b63@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=anisinha@redhat.com \
--cc=gengdongjiu1@gmail.com \
--cc=imammedo@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shannon.zhaosl@gmail.com \
--cc=shiju.jose@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.