On 2019/10/28 23:16, Peter Maydell wrote:
>> Hi Peter,
>> what do you think about it?
> I suggest you just use R: for the moment. The code will all end up going
> through my tree or perhaps Michael's anyway, so it doesn't make much
> practical difference.
ok, got it, thanks.
>
> thanks
> --
On 2019/10/28 22:56, Michael S. Tsirkin wrote:
> On Mon, Oct 28, 2019 at 09:50:21PM +0800, gengdongjiu wrote:
>> Hi Michael,
>>
>> On 2019/10/28 16:28, Michael S. Tsirkin wrote:
> gets some testing. I'll leave this decision to the ARM maintainer. For
> ACPI parts:
>
> Reviewed-by:
On Mon, 28 Oct 2019 at 15:11, gengdongjiu wrote:
>
> On 2019/10/28 22:56, Michael S. Tsirkin wrote:
> > On Mon, Oct 28, 2019 at 09:50:21PM +0800, gengdongjiu wrote:
> >> Hi Michael,
> >>
> >> On 2019/10/28 16:28, Michael S. Tsirkin wrote:
> > gets some testing. I'll leave this decision to the
On Mon, Oct 28, 2019 at 09:50:21PM +0800, gengdongjiu wrote:
> Hi Michael,
>
> On 2019/10/28 16:28, Michael S. Tsirkin wrote:
> >>> gets some testing. I'll leave this decision to the ARM maintainer. For
> >>> ACPI parts:
> >>>
> >>> Reviewed-by: Michael S. Tsirkin
> >> Got it, Thanks for the Re
Hi Michael,
On 2019/10/28 16:28, Michael S. Tsirkin wrote:
>>> gets some testing. I'll leave this decision to the ARM maintainer. For
>>> ACPI parts:
>>>
>>> Reviewed-by: Michael S. Tsirkin
>> Got it, Thanks for the Reviewed-by from Michael.
>>
>> Hi Michael,
>> According to discussion with Q
On Sun, 27 Oct 2019 at 10:17, Michael S. Tsirkin wrote:
> 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 th
Michael,
On 2019/10/28 16:28, Michael S. Tsirkin wrote:
>> 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
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 SErro
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
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
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 det
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
12 matches
Mail list logo