From: "Michael S. Tsirkin" <mst@redhat.com>
To: gengdongjiu <gengdongjiu@huawei.com>
Cc: Xiang Zheng <zhengxiang9@huawei.com>,
pbonzini@redhat.com, imammedo@redhat.com,
shannon.zhaosl@gmail.com, peter.maydell@linaro.org,
lersek@redhat.com, james.morse@arm.com, mtosatti@redhat.com,
rth@twiddle.net, ehabkost@redhat.com,
jonathan.cameron@huawei.com, xuwei5@huawei.com,
kvm@vger.kernel.org, qemu-devel@nongnu.org, qemu-arm@nongnu.org,
linuxarm@huawei.com, wanghaibin.wang@huawei.com
Subject: Re: [PATCH v20 0/5] Add ARMv8 RAS virtualization support in QEMU
Date: Mon, 28 Oct 2019 04:28:34 -0400 [thread overview]
Message-ID: <20191028042645-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <6c44268a-2676-3fa1-226d-29877b21dbea@huawei.com>
On Mon, Oct 28, 2019 at 12:01:34PM +0800, gengdongjiu wrote:
> Hi Michael/All
>
> On 2019/10/27 18:17, Michael S. Tsirkin wrote:
> > On Sat, Oct 26, 2019 at 11:24:42AM +0800, Xiang Zheng wrote:
> >> In the ARMv8 platform, the CPU error types are synchronous external abort(SEA)
> >> and SError Interrupt (SEI). If exception happens in guest, sometimes it's better
> >> for guest to perform the recovery, because host does not know the detailed
> >> information of guest. For example, if an exception happens in a user-space
> >> application within guest, host does not know which application encounters
> >> errors.
> >>
> >> For the ARMv8 SEA/SEI, KVM or host kernel delivers SIGBUS to notify userspace.
> >> After user space gets the notification, it will record the CPER into guest GHES
> >> buffer and inject an exception or IRQ into guest.
> >>
> >> In the current implementation, if the type of SIGBUS is BUS_MCEERR_AR, we will
> >> treat it as a synchronous exception, and notify guest with ARMv8 SEA
> >> notification type after recording CPER into guest.
> >>
> >> This series of patches are based on Qemu 4.1, which include two parts:
> >> 1. Generate APEI/GHES table.
> >> 2. Handle the SIGBUS signal, record the CPER in runtime and fill it into guest
> >> memory, then notify guest according to the type of SIGBUS.
> >>
> >> The whole solution was suggested by James(james.morse@arm.com); The solution of
> >> APEI section was suggested by Laszlo(lersek@redhat.com).
> >> Show some discussions in [1].
> >>
> >> This series of patches have already been tested on ARM64 platform with RAS
> >> feature enabled:
> >> Show the APEI part verification result in [2].
> >> Show the BUS_MCEERR_AR SIGBUS handling verification result in [3].
> >
> > This looks mostly OK to me. I sent some minor style comments but they
> > can be addressed by follow up patches.
> >
> > Maybe it's a good idea to merge this before soft freeze to make sure it
> > gets some testing. I'll leave this decision to the ARM maintainer. For
> > ACPI parts:
> >
> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
>
> Got it, Thanks for the Reviewed-by from Michael.
>
> Hi Michael,
> According to discussion with QEMU community, I finished and developed the whole ARM RAS virtualization solution, and introduce the ARM APEI table in the first time.
> For the newly created files, which are mainly about ARM APEI/GHES part,I would like to maintain them. If you agree it, whether I can add new maintainers[1]? thanks a lot.
>
>
> [1]:
> +ARM APEI Subsystem
> +M: Dongjiu Geng <gengdongjiu@huawei.com>
> +M: Xiang zheng <zhengxiang9@huawei.com>
> +L: qemu-arm@nongnu.org
> +S: Maintained
> +F: hw/acpi/acpi_ghes.c
> +F: include/hw/acpi/acpi_ghes.h
> +F: docs/specs/acpi_hest_ghes.rst
>
I think for now you want to be a designated reviewer. So I'd use an R:
tag.
> >
> >
> >> ---
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: gengdongjiu <gengdongjiu@huawei.com>
Cc: peter.maydell@linaro.org, ehabkost@redhat.com,
kvm@vger.kernel.org, wanghaibin.wang@huawei.com,
mtosatti@redhat.com, qemu-devel@nongnu.org, linuxarm@huawei.com,
shannon.zhaosl@gmail.com, Xiang Zheng <zhengxiang9@huawei.com>,
qemu-arm@nongnu.org, james.morse@arm.com,
jonathan.cameron@huawei.com, imammedo@redhat.com,
pbonzini@redhat.com, xuwei5@huawei.com, lersek@redhat.com,
rth@twiddle.net
Subject: Re: [PATCH v20 0/5] Add ARMv8 RAS virtualization support in QEMU
Date: Mon, 28 Oct 2019 04:28:34 -0400 [thread overview]
Message-ID: <20191028042645-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <6c44268a-2676-3fa1-226d-29877b21dbea@huawei.com>
On Mon, Oct 28, 2019 at 12:01:34PM +0800, gengdongjiu wrote:
> Hi Michael/All
>
> On 2019/10/27 18:17, Michael S. Tsirkin wrote:
> > On Sat, Oct 26, 2019 at 11:24:42AM +0800, Xiang Zheng wrote:
> >> In the ARMv8 platform, the CPU error types are synchronous external abort(SEA)
> >> and SError Interrupt (SEI). If exception happens in guest, sometimes it's better
> >> for guest to perform the recovery, because host does not know the detailed
> >> information of guest. For example, if an exception happens in a user-space
> >> application within guest, host does not know which application encounters
> >> errors.
> >>
> >> For the ARMv8 SEA/SEI, KVM or host kernel delivers SIGBUS to notify userspace.
> >> After user space gets the notification, it will record the CPER into guest GHES
> >> buffer and inject an exception or IRQ into guest.
> >>
> >> In the current implementation, if the type of SIGBUS is BUS_MCEERR_AR, we will
> >> treat it as a synchronous exception, and notify guest with ARMv8 SEA
> >> notification type after recording CPER into guest.
> >>
> >> This series of patches are based on Qemu 4.1, which include two parts:
> >> 1. Generate APEI/GHES table.
> >> 2. Handle the SIGBUS signal, record the CPER in runtime and fill it into guest
> >> memory, then notify guest according to the type of SIGBUS.
> >>
> >> The whole solution was suggested by James(james.morse@arm.com); The solution of
> >> APEI section was suggested by Laszlo(lersek@redhat.com).
> >> Show some discussions in [1].
> >>
> >> This series of patches have already been tested on ARM64 platform with RAS
> >> feature enabled:
> >> Show the APEI part verification result in [2].
> >> Show the BUS_MCEERR_AR SIGBUS handling verification result in [3].
> >
> > This looks mostly OK to me. I sent some minor style comments but they
> > can be addressed by follow up patches.
> >
> > Maybe it's a good idea to merge this before soft freeze to make sure it
> > gets some testing. I'll leave this decision to the ARM maintainer. For
> > ACPI parts:
> >
> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
>
> Got it, Thanks for the Reviewed-by from Michael.
>
> Hi Michael,
> According to discussion with QEMU community, I finished and developed the whole ARM RAS virtualization solution, and introduce the ARM APEI table in the first time.
> For the newly created files, which are mainly about ARM APEI/GHES part,I would like to maintain them. If you agree it, whether I can add new maintainers[1]? thanks a lot.
>
>
> [1]:
> +ARM APEI Subsystem
> +M: Dongjiu Geng <gengdongjiu@huawei.com>
> +M: Xiang zheng <zhengxiang9@huawei.com>
> +L: qemu-arm@nongnu.org
> +S: Maintained
> +F: hw/acpi/acpi_ghes.c
> +F: include/hw/acpi/acpi_ghes.h
> +F: docs/specs/acpi_hest_ghes.rst
>
I think for now you want to be a designated reviewer. So I'd use an R:
tag.
> >
> >
> >> ---
next prev parent reply other threads:[~2019-10-28 8:28 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-26 3:24 [PATCH v20 0/5] Add ARMv8 RAS virtualization support in QEMU Xiang Zheng
2019-10-26 3:24 ` Xiang Zheng
2019-10-26 3:24 ` [PATCH v20 1/5] hw/arm/virt: Introduce a RAS machine option Xiang Zheng
2019-10-26 3:24 ` Xiang Zheng
2019-10-26 3:24 ` [PATCH v20 2/5] docs: APEI GHES generation and CPER record description Xiang Zheng
2019-10-26 3:24 ` Xiang Zheng
2019-10-26 3:24 ` [PATCH v20 3/5] ACPI: Add APEI GHES table generation support Xiang Zheng
2019-10-26 3:24 ` Xiang Zheng
2019-10-27 10:14 ` Michael S. Tsirkin
2019-10-27 10:14 ` Michael S. Tsirkin
2019-10-30 8:51 ` Xiang Zheng
2019-10-30 8:51 ` Xiang Zheng
2019-10-26 3:24 ` [PATCH v20 4/5] KVM: Move hwpoison page related functions into kvm-all.c Xiang Zheng
2019-10-26 3:24 ` Xiang Zheng
2019-10-26 3:24 ` [PATCH v20 5/5] target-arm: kvm64: handle SIGBUS signal from kernel or KVM Xiang Zheng
2019-10-26 3:24 ` Xiang Zheng
2019-10-27 10:17 ` [PATCH v20 0/5] Add ARMv8 RAS virtualization support in QEMU Michael S. Tsirkin
2019-10-27 10:17 ` Michael S. Tsirkin
2019-10-28 3:16 ` Xiang Zheng
2019-10-28 3:16 ` Xiang Zheng
2019-10-28 4:01 ` gengdongjiu
2019-10-28 4:01 ` gengdongjiu
2019-10-28 8:28 ` Michael S. Tsirkin [this message]
2019-10-28 8:28 ` Michael S. Tsirkin
2019-10-28 12:41 ` gengdongjiu
2019-10-28 13:50 ` gengdongjiu
2019-10-28 13:50 ` gengdongjiu
2019-10-28 14:56 ` Michael S. Tsirkin
2019-10-28 14:56 ` Michael S. Tsirkin
2019-10-28 15:10 ` gengdongjiu
2019-10-28 15:10 ` gengdongjiu
2019-10-28 15:16 ` Peter Maydell
2019-10-28 15:16 ` Peter Maydell
2019-10-29 7:06 ` gengdongjiu
2019-10-29 7:06 ` gengdongjiu
2019-10-28 13:11 ` Peter Maydell
2019-10-28 13:11 ` Peter Maydell
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=20191028042645-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=ehabkost@redhat.com \
--cc=gengdongjiu@huawei.com \
--cc=imammedo@redhat.com \
--cc=james.morse@arm.com \
--cc=jonathan.cameron@huawei.com \
--cc=kvm@vger.kernel.org \
--cc=lersek@redhat.com \
--cc=linuxarm@huawei.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=shannon.zhaosl@gmail.com \
--cc=wanghaibin.wang@huawei.com \
--cc=xuwei5@huawei.com \
--cc=zhengxiang9@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.