From: Markus Armbruster <armbru@redhat.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Shiju Jose <shiju.jose@huawei.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Ani Sinha <anisinha@redhat.com>,
Dongjiu Geng <gengdongjiu1@gmail.com>,
Eric Blake <eblake@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
Michael Roth <michael.roth@amd.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
linux-kernel@vger.kernel.org, qemu-arm@nongnu.org,
qemu-devel@nongnu.org
Subject: Re: [PATCH v3 4/7] acpi/ghes: Add a logic to handle block addresses and FW first ARM processor error injection
Date: Thu, 25 Jul 2024 11:48:12 +0200 [thread overview]
Message-ID: <87bk2lreeb.fsf@pond.sub.org> (raw)
In-Reply-To: <6a3542a7d8acfbf88c906ec6f6dc5a697257b461.1721630625.git.mchehab+huawei@kernel.org> (Mauro Carvalho Chehab's message of "Mon, 22 Jul 2024 08:45:56 +0200")
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
> 1. Some GHES functions require handling addresses. Add a helper function
> to support it.
>
> 2. Add support for ACPI CPER (firmware-first) ARM processor error injection.
>
> Compliance with N.2.4.4 ARM Processor Error Section in UEFI 2.6 and
> upper specs, using error type bit encoding as detailed at UEFI 2.9A
> errata.
>
> Error injection examples:
>
> { "execute": "qmp_capabilities" }
>
> { "execute": "arm-inject-error",
> "arguments": {
> "errortypes": ['cache-error']
> }
> }
>
> { "execute": "arm-inject-error",
> "arguments": {
> "errortypes": ['tlb-error']
> }
> }
>
> { "execute": "arm-inject-error",
> "arguments": {
> "errortypes": ['bus-error']
> }
> }
>
> { "execute": "arm-inject-error",
> "arguments": {
> "errortypes": ['cache-error', 'tlb-error']
> }
> }
>
> { "execute": "arm-inject-error",
> "arguments": {
> "errortypes": ['cache-error', 'tlb-error', 'bus-error', 'micro-arch-error']
> }
> }
> ...
>
> Co-authored-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> Co-authored-by: Shiju Jose <shiju.jose@huawei.com>
> For Add a logic to handle block addresses,
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> For FW first ARM processor error injection,
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
> ---
> configs/targets/aarch64-softmmu.mak | 1 +
> hw/acpi/ghes.c | 258 ++++++++++++++++++++++++++--
> hw/arm/Kconfig | 4 +
> hw/arm/arm_error_inject.c | 35 ++++
> hw/arm/arm_error_inject_stubs.c | 18 ++
> hw/arm/meson.build | 3 +
> include/hw/acpi/ghes.h | 2 +
> qapi/arm-error-inject.json | 49 ++++++
> qapi/meson.build | 1 +
> qapi/qapi-schema.json | 1 +
> 10 files changed, 361 insertions(+), 11 deletions(-)
> create mode 100644 hw/arm/arm_error_inject.c
> create mode 100644 hw/arm/arm_error_inject_stubs.c
> create mode 100644 qapi/arm-error-inject.json
Since the new file not covered in MAINTAINERS, get_maintainer.pl will
blame it on the QAPI maintainers alone. No good.
[...]
> diff --git a/qapi/arm-error-inject.json b/qapi/arm-error-inject.json
> new file mode 100644
> index 000000000000..430e6cea6b60
> --- /dev/null
> +++ b/qapi/arm-error-inject.json
> @@ -0,0 +1,49 @@
> +# -*- Mode: Python -*-
> +# vim: filetype=python
> +
> +##
> +# = ARM Processor Errors
> +##
> +
> +##
> +# @ArmProcessorErrorType:
> +#
> +# Type of ARM processor error to inject
> +#
> +# @unknown-error: Unknown error
Removed in PATCH 7, and unused until then. Why add it in the first
place?
> +#
> +# @cache-error: Cache error
> +#
> +# @tlb-error: TLB error
> +#
> +# @bus-error: Bus error.
> +#
> +# @micro-arch-error: Micro architectural error.
> +#
> +# Since: 9.1
> +##
> +{ 'enum': 'ArmProcessorErrorType',
> + 'data': ['unknown-error',
> + 'cache-error',
Tab in this line. Please convert to spaces.
> + 'tlb-error',
> + 'bus-error',
> + 'micro-arch-error']
> +}
> +
> +##
> +# @arm-inject-error:
> +#
> +# Inject ARM Processor error.
> +#
> +# @errortypes: ARM processor error types to inject
> +#
> +# Features:
> +#
> +# @unstable: This command is experimental.
> +#
> +# Since: 9.1
> +##
> +{ 'command': 'arm-inject-error',
> + 'data': { 'errortypes': ['ArmProcessorErrorType'] },
Please separate words with dashes: 'error-types'.
> + 'features': [ 'unstable' ]
> +}
Is this used only with TARGET_ARM?
Why is being able to inject multiple error types at once useful?
I'd expect at least some of these errors to come with additional
information. For instance, I imagine a bus error is associated with
some address.
If we encode the the error to inject as an enum value, adding more will
be hard.
If we wrap the enum in a struct
{ 'struct': 'ArmProcessorError',
'data': { 'type': 'ArmProcessorErrorType' } }
we can later extend it like
{ 'union': 'ArmProcessorError',
'base: { 'type': 'ArmProcessorErrorType' }
'data': {
'bus-error': 'ArmProcessorBusErrorData' } }
{ 'struct': 'ArmProcessorBusErrorData',
'data': ... }
> diff --git a/qapi/meson.build b/qapi/meson.build
> index e7bc54e5d047..5927932c4be3 100644
> --- a/qapi/meson.build
> +++ b/qapi/meson.build
> @@ -22,6 +22,7 @@ if have_system or have_tools or have_ga
> endif
>
> qapi_all_modules = [
> + 'arm-error-inject',
> 'authz',
> 'block',
> 'block-core',
> diff --git a/qapi/qapi-schema.json b/qapi/qapi-schema.json
> index b1581988e4eb..479a22de7e43 100644
> --- a/qapi/qapi-schema.json
> +++ b/qapi/qapi-schema.json
> @@ -81,3 +81,4 @@
> { 'include': 'vfio.json' }
> { 'include': 'cryptodev.json' }
> { 'include': 'cxl.json' }
> +{ 'include': 'arm-error-inject.json' }
next prev parent reply other threads:[~2024-07-25 9:48 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-22 6:45 [PATCH v3 0/7] Add ACPI CPER firmware first error injection for Arm Processor Mauro Carvalho Chehab
2024-07-22 6:45 ` [PATCH v3 1/7] arm/virt: place power button pin number on a define Mauro Carvalho Chehab
2024-07-30 7:25 ` Igor Mammedov
2024-07-30 8:29 ` Peter Maydell
2024-07-30 11:26 ` Igor Mammedov
2024-08-01 13:15 ` Mauro Carvalho Chehab
2024-08-05 14:04 ` Igor Mammedov
2024-08-05 15:22 ` Mauro Carvalho Chehab
2024-07-22 6:45 ` [PATCH v3 2/7] arm/virt: Wire up GPIO error source for ACPI / GHES Mauro Carvalho Chehab
2024-07-26 12:30 ` Jonathan Cameron
2024-07-26 12:30 ` Jonathan Cameron via
2024-07-30 8:36 ` Igor Mammedov
2024-07-31 5:17 ` Mauro Carvalho Chehab
2024-07-22 6:45 ` [PATCH v3 3/7] acpi/ghes: Support GPIO error source Mauro Carvalho Chehab
2024-07-30 8:40 ` Igor Mammedov
2024-08-01 12:56 ` Mauro Carvalho Chehab
2024-08-01 14:32 ` Jonathan Cameron
2024-08-01 14:32 ` Jonathan Cameron via
2024-07-22 6:45 ` [PATCH v3 4/7] acpi/ghes: Add a logic to handle block addresses and FW first ARM processor error injection Mauro Carvalho Chehab
2024-07-25 9:48 ` Markus Armbruster [this message]
2024-07-26 12:46 ` Jonathan Cameron
2024-07-26 12:46 ` Jonathan Cameron via
2024-07-29 12:49 ` Mauro Carvalho Chehab
2024-07-29 12:21 ` Mauro Carvalho Chehab
2024-07-29 14:32 ` Markus Armbruster
2024-08-01 14:34 ` Mauro Carvalho Chehab
2024-07-26 12:44 ` Jonathan Cameron via
2024-07-26 12:44 ` Jonathan Cameron
2024-07-26 12:44 ` Jonathan Cameron via
2024-07-29 11:40 ` Mauro Carvalho Chehab
2024-07-30 11:17 ` Igor Mammedov
2024-07-31 7:11 ` Mauro Carvalho Chehab
2024-07-31 8:57 ` Jonathan Cameron
2024-07-31 8:57 ` Jonathan Cameron via
2024-07-31 10:30 ` Mauro Carvalho Chehab
2024-08-01 8:36 ` Igor Mammedov
2024-08-01 14:26 ` Mauro Carvalho Chehab
2024-07-22 6:45 ` [PATCH v3 5/7] target/arm: preserve mpidr value Mauro Carvalho Chehab
2024-07-26 12:50 ` Jonathan Cameron
2024-07-26 12:50 ` Jonathan Cameron via
2024-07-22 6:45 ` [PATCH v3 6/7] acpi/ghes: update comments to point to newer ACPI specs Mauro Carvalho Chehab
2024-07-30 11:24 ` Igor Mammedov
2024-07-30 11:36 ` Michael S. Tsirkin
2024-07-31 6:05 ` Mauro Carvalho Chehab
2024-07-22 6:45 ` [PATCH v3 7/7] acpi/ghes: extend arm error injection logic Mauro Carvalho Chehab
2024-07-25 10:03 ` Markus Armbruster
2024-07-29 11:18 ` Mauro Carvalho Chehab
2024-07-26 13:22 ` Jonathan Cameron
2024-07-26 13:22 ` Jonathan Cameron via
2024-07-29 11:10 ` Mauro Carvalho Chehab
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=87bk2lreeb.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=anisinha@redhat.com \
--cc=eblake@redhat.com \
--cc=gengdongjiu1@gmail.com \
--cc=imammedo@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=michael.roth@amd.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--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.