From: Will Deacon <will.deacon@arm.com>
To: Tyler Baicar <tbaicar@codeaurora.org>
Cc: linux-efi@vger.kernel.org, kvm@vger.kernel.org,
matt@codeblueprint.co.uk, catalin.marinas@arm.com,
robert.moore@intel.com, paul.gortmaker@windriver.com,
lv.zheng@intel.com, kvmarm@lists.cs.columbia.edu,
fu.wei@linaro.org, zjzhang@codeaurora.org, linux@armlinux.org.uk,
linux-acpi@vger.kernel.org, eun.taik.lee@samsung.com,
shijie.huang@arm.com, labbott@redhat.com, lenb@kernel.org,
harba@codeaurora.org, john.garry@huawei.com,
marc.zyngier@arm.com, punit.agrawal@arm.com, rostedt@goodmis.org,
nkaje@codeaurora.org, sandeepa.s.prabhu@gmail.com,
linux-arm-kernel@lists.infradead.org, devel@acpica.org,
rjw@rjwysocki.net, rruigrok@codeaurora.org,
linux-kernel@vger.kernel.org, astone@redhat.com,
hanjun.guo@linaro.org, pbonzini@redhat.com,
akpm@linux-foundation.org, bristot@redhat.com,
shiju.jose@huawei.com
Subject: Re: [PATCH V6 04/10] arm64: exception: handle Synchronous External Abort
Date: Wed, 4 Jan 2017 13:54:13 +0000 [thread overview]
Message-ID: <20170104135413.GE18193@arm.com> (raw)
In-Reply-To: <1481147303-7979-5-git-send-email-tbaicar@codeaurora.org>
On Wed, Dec 07, 2016 at 02:48:17PM -0700, Tyler Baicar wrote:
> SEA exceptions are often caused by an uncorrected hardware
> error, and are handled when data abort and instruction abort
> exception classes have specific values for their Fault Status
> Code.
> When SEA occurs, before killing the process, go through
> the handlers registered in the notification list.
> Update fault_info[] with specific SEA faults so that the
> new SEA handler is used.
>
> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
> ---
> arch/arm64/include/asm/system_misc.h | 13 ++++++++
> arch/arm64/mm/fault.c | 58 +++++++++++++++++++++++++++++-------
> 2 files changed, 61 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
> index 57f110b..9040e1d 100644
> --- a/arch/arm64/include/asm/system_misc.h
> +++ b/arch/arm64/include/asm/system_misc.h
> @@ -64,4 +64,17 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
>
> #endif /* __ASSEMBLY__ */
>
> +/*
> + * The functions below are used to register and unregister callbacks
> + * that are to be invoked when a Synchronous External Abort (SEA)
> + * occurs. An SEA is raised by certain fault status codes that have
> + * either data or instruction abort as the exception class, and
> + * callbacks may be registered to parse or handle such hardware errors.
> + *
> + * Registered callbacks are run in an interrupt/atomic context. They
> + * are not allowed to block or sleep.
> + */
> +int register_synchronous_ext_abort_notifier(struct notifier_block *nb);
> +void unregister_synchronous_ext_abort_notifier(struct notifier_block *nb);
I think that we may as well use the "SEA" acronym consistently in code,
expanding it only for strings and comments, so these can be renamed to
{register,unregister}_sea_notifier. That said, what is the use of having a
notifier chain here as well as in the ghes code? If the ghes code is the
only place to register a notifier, we may as well start simple and call that
code directly, like we call handle_mm_fault directly for data aborts.
> static const struct fault_info {
> int (*fn)(unsigned long addr, unsigned int esr, struct pt_regs *regs);
> int sig;
> @@ -502,22 +540,22 @@ static const struct fault_info {
> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 permission fault" },
> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 permission fault" },
> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 permission fault" },
> - { do_bad, SIGBUS, 0, "synchronous external abort" },
> + { do_synch_ext_abort, SIGBUS, 0, "synchronous external abort" },
Again, just stick with do_sea for the function name...
> { do_bad, SIGBUS, 0, "unknown 17" },
> { do_bad, SIGBUS, 0, "unknown 18" },
> { do_bad, SIGBUS, 0, "unknown 19" },
> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous parity error" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 0 SEA (trans tbl walk)" },
... but there's no need to abbreviate "translation table walk" here. Long
strings that run over 80 chars are fine. Similarly for "SEA".
> + { do_synch_ext_abort, SIGBUS, 0, "level 1 SEA (trans tbl walk)" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 2 SEA (trans tbl walk)" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 3 SEA (trans tbl walk)" },
> + { do_synch_ext_abort, SIGBUS, 0, "synchronous parity or ECC err" },
> { do_bad, SIGBUS, 0, "unknown 25" },
> { do_bad, SIGBUS, 0, "unknown 26" },
> { do_bad, SIGBUS, 0, "unknown 27" },
> - { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk)" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 0 synch parity error" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 1 synch parity error" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 2 synch parity error" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 3 synch parity error" },
Please keep mention of "translation table walk", since we have exception
levels too and it's confusing just saying "level n".
Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V6 04/10] arm64: exception: handle Synchronous External Abort
Date: Wed, 4 Jan 2017 13:54:13 +0000 [thread overview]
Message-ID: <20170104135413.GE18193@arm.com> (raw)
In-Reply-To: <1481147303-7979-5-git-send-email-tbaicar@codeaurora.org>
On Wed, Dec 07, 2016 at 02:48:17PM -0700, Tyler Baicar wrote:
> SEA exceptions are often caused by an uncorrected hardware
> error, and are handled when data abort and instruction abort
> exception classes have specific values for their Fault Status
> Code.
> When SEA occurs, before killing the process, go through
> the handlers registered in the notification list.
> Update fault_info[] with specific SEA faults so that the
> new SEA handler is used.
>
> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
> ---
> arch/arm64/include/asm/system_misc.h | 13 ++++++++
> arch/arm64/mm/fault.c | 58 +++++++++++++++++++++++++++++-------
> 2 files changed, 61 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
> index 57f110b..9040e1d 100644
> --- a/arch/arm64/include/asm/system_misc.h
> +++ b/arch/arm64/include/asm/system_misc.h
> @@ -64,4 +64,17 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
>
> #endif /* __ASSEMBLY__ */
>
> +/*
> + * The functions below are used to register and unregister callbacks
> + * that are to be invoked when a Synchronous External Abort (SEA)
> + * occurs. An SEA is raised by certain fault status codes that have
> + * either data or instruction abort as the exception class, and
> + * callbacks may be registered to parse or handle such hardware errors.
> + *
> + * Registered callbacks are run in an interrupt/atomic context. They
> + * are not allowed to block or sleep.
> + */
> +int register_synchronous_ext_abort_notifier(struct notifier_block *nb);
> +void unregister_synchronous_ext_abort_notifier(struct notifier_block *nb);
I think that we may as well use the "SEA" acronym consistently in code,
expanding it only for strings and comments, so these can be renamed to
{register,unregister}_sea_notifier. That said, what is the use of having a
notifier chain here as well as in the ghes code? If the ghes code is the
only place to register a notifier, we may as well start simple and call that
code directly, like we call handle_mm_fault directly for data aborts.
> static const struct fault_info {
> int (*fn)(unsigned long addr, unsigned int esr, struct pt_regs *regs);
> int sig;
> @@ -502,22 +540,22 @@ static const struct fault_info {
> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 permission fault" },
> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 permission fault" },
> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 permission fault" },
> - { do_bad, SIGBUS, 0, "synchronous external abort" },
> + { do_synch_ext_abort, SIGBUS, 0, "synchronous external abort" },
Again, just stick with do_sea for the function name...
> { do_bad, SIGBUS, 0, "unknown 17" },
> { do_bad, SIGBUS, 0, "unknown 18" },
> { do_bad, SIGBUS, 0, "unknown 19" },
> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous parity error" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 0 SEA (trans tbl walk)" },
... but there's no need to abbreviate "translation table walk" here. Long
strings that run over 80 chars are fine. Similarly for "SEA".
> + { do_synch_ext_abort, SIGBUS, 0, "level 1 SEA (trans tbl walk)" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 2 SEA (trans tbl walk)" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 3 SEA (trans tbl walk)" },
> + { do_synch_ext_abort, SIGBUS, 0, "synchronous parity or ECC err" },
> { do_bad, SIGBUS, 0, "unknown 25" },
> { do_bad, SIGBUS, 0, "unknown 26" },
> { do_bad, SIGBUS, 0, "unknown 27" },
> - { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk)" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 0 synch parity error" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 1 synch parity error" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 2 synch parity error" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 3 synch parity error" },
Please keep mention of "translation table walk", since we have exception
levels too and it's confusing just saying "level n".
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Tyler Baicar <tbaicar@codeaurora.org>
Cc: christoffer.dall@linaro.org, marc.zyngier@arm.com,
pbonzini@redhat.com, rkrcmar@redhat.com, linux@armlinux.org.uk,
catalin.marinas@arm.com, rjw@rjwysocki.net, lenb@kernel.org,
matt@codeblueprint.co.uk, robert.moore@intel.com,
lv.zheng@intel.com, nkaje@codeaurora.org, zjzhang@codeaurora.org,
mark.rutland@arm.com, james.morse@arm.com,
akpm@linux-foundation.org, eun.taik.lee@samsung.com,
sandeepa.s.prabhu@gmail.com, labbott@redhat.com,
shijie.huang@arm.com, rruigrok@codeaurora.org,
paul.gortmaker@windriver.com, tn@semihalf.com, fu.wei@linaro.org,
rostedt@goodmis.org, bristot@redhat.com,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-efi@vger.kernel.org, devel@acpica.org,
Suzuki.Poulose@arm.com, punit.agrawal@arm.com, astone@redhat.com,
harba@codeaurora.org, hanjun.guo@linaro.org,
john.garry@huawei.com, shiju.jose@huawei.com
Subject: Re: [PATCH V6 04/10] arm64: exception: handle Synchronous External Abort
Date: Wed, 4 Jan 2017 13:54:13 +0000 [thread overview]
Message-ID: <20170104135413.GE18193@arm.com> (raw)
In-Reply-To: <1481147303-7979-5-git-send-email-tbaicar@codeaurora.org>
On Wed, Dec 07, 2016 at 02:48:17PM -0700, Tyler Baicar wrote:
> SEA exceptions are often caused by an uncorrected hardware
> error, and are handled when data abort and instruction abort
> exception classes have specific values for their Fault Status
> Code.
> When SEA occurs, before killing the process, go through
> the handlers registered in the notification list.
> Update fault_info[] with specific SEA faults so that the
> new SEA handler is used.
>
> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
> ---
> arch/arm64/include/asm/system_misc.h | 13 ++++++++
> arch/arm64/mm/fault.c | 58 +++++++++++++++++++++++++++++-------
> 2 files changed, 61 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
> index 57f110b..9040e1d 100644
> --- a/arch/arm64/include/asm/system_misc.h
> +++ b/arch/arm64/include/asm/system_misc.h
> @@ -64,4 +64,17 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
>
> #endif /* __ASSEMBLY__ */
>
> +/*
> + * The functions below are used to register and unregister callbacks
> + * that are to be invoked when a Synchronous External Abort (SEA)
> + * occurs. An SEA is raised by certain fault status codes that have
> + * either data or instruction abort as the exception class, and
> + * callbacks may be registered to parse or handle such hardware errors.
> + *
> + * Registered callbacks are run in an interrupt/atomic context. They
> + * are not allowed to block or sleep.
> + */
> +int register_synchronous_ext_abort_notifier(struct notifier_block *nb);
> +void unregister_synchronous_ext_abort_notifier(struct notifier_block *nb);
I think that we may as well use the "SEA" acronym consistently in code,
expanding it only for strings and comments, so these can be renamed to
{register,unregister}_sea_notifier. That said, what is the use of having a
notifier chain here as well as in the ghes code? If the ghes code is the
only place to register a notifier, we may as well start simple and call that
code directly, like we call handle_mm_fault directly for data aborts.
> static const struct fault_info {
> int (*fn)(unsigned long addr, unsigned int esr, struct pt_regs *regs);
> int sig;
> @@ -502,22 +540,22 @@ static const struct fault_info {
> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 permission fault" },
> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 permission fault" },
> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 permission fault" },
> - { do_bad, SIGBUS, 0, "synchronous external abort" },
> + { do_synch_ext_abort, SIGBUS, 0, "synchronous external abort" },
Again, just stick with do_sea for the function name...
> { do_bad, SIGBUS, 0, "unknown 17" },
> { do_bad, SIGBUS, 0, "unknown 18" },
> { do_bad, SIGBUS, 0, "unknown 19" },
> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous parity error" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 0 SEA (trans tbl walk)" },
... but there's no need to abbreviate "translation table walk" here. Long
strings that run over 80 chars are fine. Similarly for "SEA".
> + { do_synch_ext_abort, SIGBUS, 0, "level 1 SEA (trans tbl walk)" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 2 SEA (trans tbl walk)" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 3 SEA (trans tbl walk)" },
> + { do_synch_ext_abort, SIGBUS, 0, "synchronous parity or ECC err" },
> { do_bad, SIGBUS, 0, "unknown 25" },
> { do_bad, SIGBUS, 0, "unknown 26" },
> { do_bad, SIGBUS, 0, "unknown 27" },
> - { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk)" },
> - { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk)" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 0 synch parity error" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 1 synch parity error" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 2 synch parity error" },
> + { do_synch_ext_abort, SIGBUS, 0, "level 3 synch parity error" },
Please keep mention of "translation table walk", since we have exception
levels too and it's confusing just saying "level n".
Will
next prev parent reply other threads:[~2017-01-04 13:52 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-07 21:48 [PATCH V6 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64 Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` [PATCH V6 01/10] acpi: apei: read ack upon ghes record consumption Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` [PATCH V6 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1 Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` [PATCH V6 03/10] efi: parse ARM processor error Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-15 14:08 ` James Morse
2016-12-15 14:08 ` James Morse
2016-12-15 14:08 ` James Morse
2017-01-05 21:17 ` Baicar, Tyler
2017-01-05 21:17 ` Baicar, Tyler
2017-01-05 21:17 ` Baicar, Tyler
2016-12-07 21:48 ` [PATCH V6 04/10] arm64: exception: handle Synchronous External Abort Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2017-01-04 13:54 ` Will Deacon [this message]
2017-01-04 13:54 ` Will Deacon
2017-01-04 13:54 ` Will Deacon
2017-01-06 16:58 ` Baicar, Tyler
2017-01-06 16:58 ` Baicar, Tyler
2017-01-06 16:58 ` Baicar, Tyler
2016-12-07 21:48 ` [PATCH V6 05/10] acpi: apei: handle SEA notification type for ARMv8 Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
[not found] ` <1481147303-7979-6-git-send-email-tbaicar-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-12-20 15:29 ` James Morse
2016-12-20 15:29 ` James Morse
2016-12-20 15:29 ` James Morse
2017-01-05 22:31 ` Baicar, Tyler
2017-01-05 22:31 ` Baicar, Tyler
2017-01-05 22:31 ` Baicar, Tyler
2017-01-06 10:43 ` James Morse
2017-01-06 10:43 ` James Morse
2017-01-06 10:43 ` James Morse
2017-01-10 17:50 ` Baicar, Tyler
2017-01-10 17:50 ` Baicar, Tyler
2017-01-10 17:50 ` Baicar, Tyler
2016-12-07 21:48 ` [PATCH V6 06/10] acpi: apei: panic OS with fatal error status block Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` [PATCH V6 07/10] efi: print unrecognized CPER section Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` [PATCH V6 08/10] ras: acpi / apei: generate trace event for " Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` [PATCH V6 09/10] trace, ras: add ARM processor error trace event Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` [PATCH V6 10/10] arm/arm64: KVM: add guest SEA support Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-07 21:48 ` Tyler Baicar
2016-12-13 11:10 ` [PATCH V6 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64 Shiju Jose
2016-12-13 11:10 ` Shiju Jose
2016-12-13 18:38 ` Baicar, Tyler
2016-12-13 18:38 ` Baicar, Tyler
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=20170104135413.GE18193@arm.com \
--to=will.deacon@arm.com \
--cc=akpm@linux-foundation.org \
--cc=astone@redhat.com \
--cc=bristot@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=devel@acpica.org \
--cc=eun.taik.lee@samsung.com \
--cc=fu.wei@linaro.org \
--cc=hanjun.guo@linaro.org \
--cc=harba@codeaurora.org \
--cc=john.garry@huawei.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=labbott@redhat.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=lv.zheng@intel.com \
--cc=marc.zyngier@arm.com \
--cc=matt@codeblueprint.co.uk \
--cc=nkaje@codeaurora.org \
--cc=paul.gortmaker@windriver.com \
--cc=pbonzini@redhat.com \
--cc=punit.agrawal@arm.com \
--cc=rjw@rjwysocki.net \
--cc=robert.moore@intel.com \
--cc=rostedt@goodmis.org \
--cc=rruigrok@codeaurora.org \
--cc=sandeepa.s.prabhu@gmail.com \
--cc=shijie.huang@arm.com \
--cc=shiju.jose@huawei.com \
--cc=tbaicar@codeaurora.org \
--cc=zjzhang@codeaurora.org \
/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.