All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: gengdongjiu <gengdongjiu@huawei.com>, Achin Gupta <achin.gupta@arm.com>
Cc: ard.biesheuvel@linaro.org, edk2-devel@ml01.01.org,
	qemu-devel@nongnu.org, zhaoshenglong@huawei.com,
	James Morse <james.morse@arm.com>,
	Christoffer Dall <cdall@linaro.org>,
	xiexiuqi@huawei.com, Marc Zyngier <marc.zyngier@arm.com>,
	catalin.marinas@arm.com, will.deacon@arm.com,
	christoffer.dall@linaro.org, rkrcmar@redhat.com,
	suzuki.poulose@arm.com, andre.przywara@arm.com,
	mark.rutland@arm.com, vladimir.murzin@arm.com,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, wangxiongfeng2@huawei.com,
	wuquanming@huawei.com, huangshaoyu@huawei.com,
	Leif.Lindholm@linaro.com, nd@arm.com,
	Michael Tsirkin <mtsirkin@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>
Subject: Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS
Date: Fri, 7 Apr 2017 11:21:41 +0200	[thread overview]
Message-ID: <09c64b28-5eb5-4efd-6cb8-035b69313a99@redhat.com> (raw)
In-Reply-To: <55546a4b-c33b-37b9-dafe-15ce75bc1b62@huawei.com>

On 04/07/17 04:52, gengdongjiu wrote:
> 
> On 2017/4/7 2:55, Laszlo Ersek wrote:

>> I'm unsure if, by "not fixed", you are saying
>>
>>   the number of CPER entries that fits in Error Status Data Block N is
>>   not *uniform* across 0 <= N <= 10 [1]
>>
>> or
>>
>>   the number of CPER entries that fits in Error Status Data Block N is
>>   not *known* in advance, for all of 0 <= N <= 10 [2]
>>
>> Which one is your point?
>>
>> If [1], that's no problem; you can simply sum the individual error
>> status data block sizes in advance, and allocate "etc/hardware_errors"
>> accordingly, using the total size.
>>
>> (Allocating one shared fw_cfg blob for all status data blocks is more
>> memory efficient, as each ALLOCATE command will allocate whole pages
>> (rounded up from the actual blob size).)
>>
>> If your point is [2], then splitting the error status data blocks to
>> separate fw_cfg blobs makes no difference: regardless of whether we try
>> to place all the error status data blocks in a single fw_cfg blob, or in
>> separate fw_cfg blobs, the individual data block cannot be resized at OS
>> runtime, so there's no way to make it work.
>>
> My Point is [2]. The HEST(Hardware Error Source Table) table format is here:
> https://wiki.linaro.org/LEG/Engineering/Kernel/RAS/APEITables#Hardware_Error_Source_Table_.28HEST.29
> 
> Now I understand your thought.

But if you mean [2], then I am confused, with regard to firmware on
physical hardware. Namely, even on physical machines, the firmware has
to estimate, in advance, the area size that will be needed for CPERs,
doesn't it? And once the firmware allocates that memory area, it cannot
be resized at OS runtime. If there are more CPERs at runtime (due to
hardware errors) than the firmware allocated room for, they must surely
wrap around in the preallocated buffer (like in a ring buffer). Isn't
that correct?

On the diagrams that you linked above (great looking diagrams BTW!), I
see CPER in two places (it is helpfully shaded red):

- to the right of BERT; the CPER is part of a box that is captioned
"firmware reserved memory"

- to the right of HEST; again the CPER is part of a box that is
captioned "firmware reserved memory"

So, IMO, when QEMU has to guesstimate the room for CPERs in advance,
that doesn't differ from the physical firmware case. In QEMU maybe you
can let the user specify the area size on the command line, with a
machine type property or similar.

Thanks
Laszlo

WARNING: multiple messages have this Message-ID (diff)
From: Laszlo Ersek <lersek@redhat.com>
To: gengdongjiu <gengdongjiu@huawei.com>, Achin Gupta <achin.gupta@arm.com>
Cc: Michael Tsirkin <mtsirkin@redhat.com>,
	kvm@vger.kernel.org, rkrcmar@redhat.com, catalin.marinas@arm.com,
	will.deacon@arm.com, qemu-devel@nongnu.org,
	wuquanming@huawei.com, wangxiongfeng2@huawei.com,
	Christoffer Dall <cdall@linaro.org>,
	suzuki.poulose@arm.com, kvmarm@lists.cs.columbia.edu,
	Leif.Lindholm@linaro.com, huangshaoyu@huawei.com,
	vladimir.murzin@arm.com, xiexiuqi@huawei.com,
	Marc Zyngier <marc.zyngier@arm.com>,
	andre.przywara@arm.com, edk2-devel@lists.01.org, nd@arm.com,
	linux-arm-kernel@lists.infradead.org, ard.biesheuvel@linaro.org,
	linux-kernel@vger.kernel.org, James Morse <james.morse@arm.com>,
	christoffer.dall@linaro.org
Subject: Re: [edk2] [PATCH] kvm: pass the virtual SEI syndrome to guest OS
Date: Fri, 7 Apr 2017 11:21:41 +0200	[thread overview]
Message-ID: <09c64b28-5eb5-4efd-6cb8-035b69313a99@redhat.com> (raw)
In-Reply-To: <55546a4b-c33b-37b9-dafe-15ce75bc1b62@huawei.com>

On 04/07/17 04:52, gengdongjiu wrote:
> 
> On 2017/4/7 2:55, Laszlo Ersek wrote:

>> I'm unsure if, by "not fixed", you are saying
>>
>>   the number of CPER entries that fits in Error Status Data Block N is
>>   not *uniform* across 0 <= N <= 10 [1]
>>
>> or
>>
>>   the number of CPER entries that fits in Error Status Data Block N is
>>   not *known* in advance, for all of 0 <= N <= 10 [2]
>>
>> Which one is your point?
>>
>> If [1], that's no problem; you can simply sum the individual error
>> status data block sizes in advance, and allocate "etc/hardware_errors"
>> accordingly, using the total size.
>>
>> (Allocating one shared fw_cfg blob for all status data blocks is more
>> memory efficient, as each ALLOCATE command will allocate whole pages
>> (rounded up from the actual blob size).)
>>
>> If your point is [2], then splitting the error status data blocks to
>> separate fw_cfg blobs makes no difference: regardless of whether we try
>> to place all the error status data blocks in a single fw_cfg blob, or in
>> separate fw_cfg blobs, the individual data block cannot be resized at OS
>> runtime, so there's no way to make it work.
>>
> My Point is [2]. The HEST(Hardware Error Source Table) table format is here:
> https://wiki.linaro.org/LEG/Engineering/Kernel/RAS/APEITables#Hardware_Error_Source_Table_.28HEST.29
> 
> Now I understand your thought.

But if you mean [2], then I am confused, with regard to firmware on
physical hardware. Namely, even on physical machines, the firmware has
to estimate, in advance, the area size that will be needed for CPERs,
doesn't it? And once the firmware allocates that memory area, it cannot
be resized at OS runtime. If there are more CPERs at runtime (due to
hardware errors) than the firmware allocated room for, they must surely
wrap around in the preallocated buffer (like in a ring buffer). Isn't
that correct?

On the diagrams that you linked above (great looking diagrams BTW!), I
see CPER in two places (it is helpfully shaded red):

- to the right of BERT; the CPER is part of a box that is captioned
"firmware reserved memory"

- to the right of HEST; again the CPER is part of a box that is
captioned "firmware reserved memory"

So, IMO, when QEMU has to guesstimate the room for CPERs in advance,
that doesn't differ from the physical firmware case. In QEMU maybe you
can let the user specify the area size on the command line, with a
machine type property or similar.

Thanks
Laszlo

WARNING: multiple messages have this Message-ID (diff)
From: Laszlo Ersek <lersek@redhat.com>
To: gengdongjiu <gengdongjiu@huawei.com>, Achin Gupta <achin.gupta@arm.com>
Cc: ard.biesheuvel@linaro.org, edk2-devel@lists.01.org,
	qemu-devel@nongnu.org, zhaoshenglong@huawei.com,
	James Morse <james.morse@arm.com>,
	Christoffer Dall <cdall@linaro.org>,
	xiexiuqi@huawei.com, Marc Zyngier <marc.zyngier@arm.com>,
	catalin.marinas@arm.com, will.deacon@arm.com,
	christoffer.dall@linaro.org, rkrcmar@redhat.com,
	suzuki.poulose@arm.com, andre.przywara@arm.com,
	mark.rutland@arm.com, vladimir.murzin@arm.com,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, wangxiongfeng2@huawei.com,
	wuquanming@huawei.com, huangshaoyu@huawei.com,
	Leif.Lindholm@linaro.comnd@arm.com,
	Michael Tsirkin <mtsirkin@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] kvm: pass the virtual SEI syndrome to guest OS
Date: Fri, 7 Apr 2017 11:21:41 +0200	[thread overview]
Message-ID: <09c64b28-5eb5-4efd-6cb8-035b69313a99@redhat.com> (raw)
In-Reply-To: <55546a4b-c33b-37b9-dafe-15ce75bc1b62@huawei.com>

On 04/07/17 04:52, gengdongjiu wrote:
> 
> On 2017/4/7 2:55, Laszlo Ersek wrote:

>> I'm unsure if, by "not fixed", you are saying
>>
>>   the number of CPER entries that fits in Error Status Data Block N is
>>   not *uniform* across 0 <= N <= 10 [1]
>>
>> or
>>
>>   the number of CPER entries that fits in Error Status Data Block N is
>>   not *known* in advance, for all of 0 <= N <= 10 [2]
>>
>> Which one is your point?
>>
>> If [1], that's no problem; you can simply sum the individual error
>> status data block sizes in advance, and allocate "etc/hardware_errors"
>> accordingly, using the total size.
>>
>> (Allocating one shared fw_cfg blob for all status data blocks is more
>> memory efficient, as each ALLOCATE command will allocate whole pages
>> (rounded up from the actual blob size).)
>>
>> If your point is [2], then splitting the error status data blocks to
>> separate fw_cfg blobs makes no difference: regardless of whether we try
>> to place all the error status data blocks in a single fw_cfg blob, or in
>> separate fw_cfg blobs, the individual data block cannot be resized at OS
>> runtime, so there's no way to make it work.
>>
> My Point is [2]. The HEST(Hardware Error Source Table) table format is here:
> https://wiki.linaro.org/LEG/Engineering/Kernel/RAS/APEITables#Hardware_Error_Source_Table_.28HEST.29
> 
> Now I understand your thought.

But if you mean [2], then I am confused, with regard to firmware on
physical hardware. Namely, even on physical machines, the firmware has
to estimate, in advance, the area size that will be needed for CPERs,
doesn't it? And once the firmware allocates that memory area, it cannot
be resized at OS runtime. If there are more CPERs at runtime (due to
hardware errors) than the firmware allocated room for, they must surely
wrap around in the preallocated buffer (like in a ring buffer). Isn't
that correct?

On the diagrams that you linked above (great looking diagrams BTW!), I
see CPER in two places (it is helpfully shaded red):

- to the right of BERT; the CPER is part of a box that is captioned
"firmware reserved memory"

- to the right of HEST; again the CPER is part of a box that is
captioned "firmware reserved memory"

So, IMO, when QEMU has to guesstimate the room for CPERs in advance,
that doesn't differ from the physical firmware case. In QEMU maybe you
can let the user specify the area size on the command line, with a
machine type property or similar.

Thanks
Laszlo

WARNING: multiple messages have this Message-ID (diff)
From: lersek@redhat.com (Laszlo Ersek)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] kvm: pass the virtual SEI syndrome to guest OS
Date: Fri, 7 Apr 2017 11:21:41 +0200	[thread overview]
Message-ID: <09c64b28-5eb5-4efd-6cb8-035b69313a99@redhat.com> (raw)
In-Reply-To: <55546a4b-c33b-37b9-dafe-15ce75bc1b62@huawei.com>

On 04/07/17 04:52, gengdongjiu wrote:
> 
> On 2017/4/7 2:55, Laszlo Ersek wrote:

>> I'm unsure if, by "not fixed", you are saying
>>
>>   the number of CPER entries that fits in Error Status Data Block N is
>>   not *uniform* across 0 <= N <= 10 [1]
>>
>> or
>>
>>   the number of CPER entries that fits in Error Status Data Block N is
>>   not *known* in advance, for all of 0 <= N <= 10 [2]
>>
>> Which one is your point?
>>
>> If [1], that's no problem; you can simply sum the individual error
>> status data block sizes in advance, and allocate "etc/hardware_errors"
>> accordingly, using the total size.
>>
>> (Allocating one shared fw_cfg blob for all status data blocks is more
>> memory efficient, as each ALLOCATE command will allocate whole pages
>> (rounded up from the actual blob size).)
>>
>> If your point is [2], then splitting the error status data blocks to
>> separate fw_cfg blobs makes no difference: regardless of whether we try
>> to place all the error status data blocks in a single fw_cfg blob, or in
>> separate fw_cfg blobs, the individual data block cannot be resized at OS
>> runtime, so there's no way to make it work.
>>
> My Point is [2]. The HEST(Hardware Error Source Table) table format is here:
> https://wiki.linaro.org/LEG/Engineering/Kernel/RAS/APEITables#Hardware_Error_Source_Table_.28HEST.29
> 
> Now I understand your thought.

But if you mean [2], then I am confused, with regard to firmware on
physical hardware. Namely, even on physical machines, the firmware has
to estimate, in advance, the area size that will be needed for CPERs,
doesn't it? And once the firmware allocates that memory area, it cannot
be resized at OS runtime. If there are more CPERs at runtime (due to
hardware errors) than the firmware allocated room for, they must surely
wrap around in the preallocated buffer (like in a ring buffer). Isn't
that correct?

On the diagrams that you linked above (great looking diagrams BTW!), I
see CPER in two places (it is helpfully shaded red):

- to the right of BERT; the CPER is part of a box that is captioned
"firmware reserved memory"

- to the right of HEST; again the CPER is part of a box that is
captioned "firmware reserved memory"

So, IMO, when QEMU has to guesstimate the room for CPERs in advance,
that doesn't differ from the physical firmware case. In QEMU maybe you
can let the user specify the area size on the command line, with a
machine type property or similar.

Thanks
Laszlo

  reply	other threads:[~2017-04-07  9:22 UTC|newest]

Thread overview: 164+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-20  7:55 [PATCH] kvm: pass the virtual SEI syndrome to guest OS Dongjiu Geng
2017-03-20  7:55 ` Dongjiu Geng
2017-03-20  7:55 ` Dongjiu Geng
2017-03-20  7:55 ` Dongjiu Geng
2017-03-20 11:24 ` Marc Zyngier
2017-03-20 11:24   ` Marc Zyngier
2017-03-20 11:24   ` Marc Zyngier
2017-03-20 12:28   ` gengdongjiu
2017-03-20 12:28     ` gengdongjiu
2017-03-20 12:28     ` gengdongjiu
2017-03-20 12:28     ` gengdongjiu
2017-03-20 13:58     ` Marc Zyngier
2017-03-20 13:58       ` Marc Zyngier
2017-03-20 13:58       ` Marc Zyngier
2017-03-20 15:08       ` James Morse
2017-03-20 15:08         ` James Morse
2017-03-20 15:08         ` James Morse
2017-03-21  6:32         ` gengdongjiu
2017-03-21  6:32           ` gengdongjiu
2017-03-21  6:32           ` gengdongjiu
2017-03-21  6:32           ` gengdongjiu
2017-03-21 11:34           ` Christoffer Dall
2017-03-21 11:34             ` Christoffer Dall
2017-03-21 11:34             ` Christoffer Dall
2017-03-21 19:11             ` James Morse
2017-03-21 19:11               ` James Morse
2017-03-21 19:11               ` James Morse
2017-03-21 19:36               ` Christoffer Dall
2017-03-21 19:39               ` Christoffer Dall
2017-03-21 19:39                 ` Christoffer Dall
2017-03-21 19:39                 ` Christoffer Dall
2017-03-21 22:10                 ` Peter Maydell
2017-03-21 22:10                   ` Peter Maydell
2017-03-21 22:10                   ` Peter Maydell
2017-03-22 11:15                   ` Marc Zyngier
2017-03-22 11:15                     ` Marc Zyngier
2017-03-22 11:15                     ` Marc Zyngier
2017-03-28 10:48                 ` James Morse
2017-03-28 10:48                   ` James Morse
2017-03-28 10:48                   ` James Morse
2017-03-28 11:23                   ` Christoffer Dall
2017-03-28 11:23                     ` Christoffer Dall
2017-03-28 11:23                     ` Christoffer Dall
2017-03-28 11:33                     ` Peter Maydell
2017-03-28 11:33                       ` Peter Maydell
2017-03-28 11:33                       ` Peter Maydell
2017-03-28 13:27                       ` James Morse
2017-03-28 13:27                         ` James Morse
2017-03-28 13:27                         ` James Morse
2017-03-28 11:54                     ` Achin Gupta
2017-03-28 11:54                       ` Achin Gupta
2017-03-28 11:54                       ` Achin Gupta
2017-03-28 12:16                       ` gengdongjiu
2017-03-28 12:16                         ` gengdongjiu
2017-03-28 12:16                         ` gengdongjiu
2017-03-28 13:40                         ` James Morse
2017-03-28 13:40                           ` James Morse
2017-03-28 13:40                           ` James Morse
2017-03-29  9:36                           ` gengdongjiu
2017-03-29  9:36                             ` gengdongjiu
2017-03-29  9:36                             ` gengdongjiu
2017-03-29  9:36                             ` [Qemu-devel] " gengdongjiu
2017-03-29  9:36                             ` gengdongjiu
2017-03-29 10:36                             ` Achin Gupta
2017-03-29 10:36                               ` Achin Gupta
2017-03-29 10:36                               ` [Qemu-devel] " Achin Gupta
2017-03-29 10:36                               ` Achin Gupta
2017-03-29 11:58                               ` Laszlo Ersek
2017-03-29 11:58                                 ` Laszlo Ersek
2017-03-29 11:58                                 ` [Qemu-devel] " Laszlo Ersek
2017-03-29 11:58                                 ` [edk2] " Laszlo Ersek
2017-03-29 12:51                                 ` Michael S. Tsirkin
2017-03-29 12:51                                   ` Michael S. Tsirkin
2017-03-29 12:51                                   ` Michael S. Tsirkin
2017-03-29 12:51                                   ` [Qemu-devel] " Michael S. Tsirkin
2017-03-29 12:51                                   ` Michael S. Tsirkin
2017-03-29 13:36                                   ` Laszlo Ersek
2017-03-29 13:36                                     ` Laszlo Ersek
2017-03-29 13:36                                     ` [Qemu-devel] " Laszlo Ersek
2017-03-29 13:36                                     ` Laszlo Ersek
2017-03-29 13:54                                     ` Michael S. Tsirkin
2017-03-29 13:54                                       ` Michael S. Tsirkin
2017-03-29 13:54                                       ` Michael S. Tsirkin
2017-03-29 13:54                                       ` [Qemu-devel] " Michael S. Tsirkin
2017-03-29 13:54                                       ` Michael S. Tsirkin
2017-03-29 13:56                                     ` Punit Agrawal
2017-03-29 13:56                                       ` Punit Agrawal
2017-03-29 13:56                                       ` [Qemu-devel] " Punit Agrawal
2017-03-29 13:56                                       ` Punit Agrawal
2017-04-06 12:35                                 ` gengdongjiu
2017-04-06 12:35                                   ` gengdongjiu
2017-04-06 12:35                                   ` gengdongjiu
2017-04-06 12:35                                   ` [Qemu-devel] " gengdongjiu
2017-04-06 12:35                                   ` gengdongjiu
2017-04-06 18:55                                   ` Laszlo Ersek
2017-04-06 18:55                                     ` Laszlo Ersek
2017-04-06 18:55                                     ` [Qemu-devel] " Laszlo Ersek
2017-04-06 18:55                                     ` [edk2] " Laszlo Ersek
2017-04-07  2:52                                     ` gengdongjiu
2017-04-07  2:52                                       ` gengdongjiu
2017-04-07  2:52                                       ` [Qemu-devel] " gengdongjiu
2017-04-07  2:52                                       ` [edk2] " gengdongjiu
2017-04-07  9:21                                       ` Laszlo Ersek [this message]
2017-04-07  9:21                                         ` Laszlo Ersek
2017-04-07  9:21                                         ` [Qemu-devel] " Laszlo Ersek
2017-04-07  9:21                                         ` [edk2] " Laszlo Ersek
2017-04-21 13:27                                     ` gengdongjiu
2017-04-21 13:27                                       ` gengdongjiu
2017-04-21 13:27                                       ` [Qemu-devel] " gengdongjiu
2017-04-21 13:27                                       ` [edk2] " gengdongjiu
2017-04-24 11:27                                       ` Laszlo Ersek
2017-04-24 11:27                                         ` Laszlo Ersek
2017-04-24 11:27                                         ` [Qemu-devel] " Laszlo Ersek
2017-04-24 11:27                                         ` [edk2] " Laszlo Ersek
2017-03-29 14:36                               ` gengdongjiu
2017-03-29 14:36                                 ` gengdongjiu
2017-03-29 14:36                                 ` gengdongjiu
2017-03-29 14:36                                 ` [Qemu-devel] " gengdongjiu
2017-03-29 14:36                                 ` gengdongjiu
2017-03-29 14:48                                 ` Christoffer Dall
2017-03-29 14:48                                   ` Christoffer Dall
2017-03-29 14:48                                   ` Christoffer Dall
2017-03-29 14:48                                   ` [Qemu-devel] " Christoffer Dall
2017-03-29 14:48                                   ` Christoffer Dall
2017-03-29 15:37                                   ` Laszlo Ersek
2017-03-29 15:37                                     ` Laszlo Ersek
2017-03-29 15:37                                     ` [Qemu-devel] " Laszlo Ersek
2017-03-29 15:37                                     ` [edk2] " Laszlo Ersek
2017-03-29 17:44                                     ` Christoffer Dall
2017-03-29 17:44                                       ` Christoffer Dall
2017-03-29 17:44                                       ` [Qemu-devel] " Christoffer Dall
2017-03-29 17:44                                       ` Christoffer Dall
2017-03-30  1:22                                       ` gengdongjiu
2017-03-30  1:22                                         ` gengdongjiu
2017-03-30  1:22                                         ` gengdongjiu
2017-03-30  1:22                                         ` [Qemu-devel] " gengdongjiu
2017-03-30  1:22                                         ` gengdongjiu
2017-03-28 12:22                       ` Christoffer Dall
2017-03-28 12:22                         ` Christoffer Dall
2017-03-28 12:22                         ` Christoffer Dall
2017-03-28 13:24                         ` Achin Gupta
2017-03-28 13:24                           ` Achin Gupta
2017-03-28 13:24                           ` Achin Gupta
2017-03-28 13:40                           ` Christoffer Dall
2017-03-28 13:40                             ` Christoffer Dall
2017-03-28 13:40                             ` Christoffer Dall
2017-03-21 13:10           ` James Morse
2017-03-21 13:10             ` James Morse
2017-03-21 13:10             ` James Morse
2017-03-22 13:37             ` gengdongjiu
2017-03-22 13:37               ` gengdongjiu
2017-03-22 13:37               ` gengdongjiu
2017-03-22 18:56               ` James Morse
2017-03-22 18:56                 ` James Morse
2017-03-22 18:56                 ` James Morse
2017-03-21  6:07       ` gengdongjiu
2017-03-21  6:07         ` gengdongjiu
2017-03-21  6:07         ` gengdongjiu
2017-03-21 13:51 ` kbuild test robot
2017-03-21 13:51   ` kbuild test robot
2017-03-21 13:51   ` kbuild test robot
2017-03-22  3:20   ` gengdongjiu
2017-03-22  3:20     ` gengdongjiu
2017-03-22  3:20     ` gengdongjiu

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=09c64b28-5eb5-4efd-6cb8-035b69313a99@redhat.com \
    --to=lersek@redhat.com \
    --cc=Leif.Lindholm@linaro.com \
    --cc=achin.gupta@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=cdall@linaro.org \
    --cc=christoffer.dall@linaro.org \
    --cc=edk2-devel@ml01.01.org \
    --cc=gengdongjiu@huawei.com \
    --cc=huangshaoyu@huawei.com \
    --cc=imammedo@redhat.com \
    --cc=james.morse@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=mtsirkin@redhat.com \
    --cc=nd@arm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rkrcmar@redhat.com \
    --cc=suzuki.poulose@arm.com \
    --cc=vladimir.murzin@arm.com \
    --cc=wangxiongfeng2@huawei.com \
    --cc=will.deacon@arm.com \
    --cc=wuquanming@huawei.com \
    --cc=xiexiuqi@huawei.com \
    --cc=zhaoshenglong@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.