[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [PATCH v14 2/9] ACPI: Add APEI GHES table generation and
From: |
gengdongjiu |
Subject: |
Re: [Qemu-arm] [PATCH v14 2/9] ACPI: Add APEI GHES table generation and CPER record support |
Date: |
Wed, 10 Jan 2018 13:22:30 +0800 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
Peter,
Thank you very much for your time to review it and give some comments.
On 2018/1/10 0:51, Peter Maydell wrote:
>> the error type to Multi-bit ECC.
>>
>> [1]:
>> UEFI Spec 2.6 Errata A:
>>
>> "N.2.5 Memory Error Section"
>> -----------------+---------------+--------------+-------------------------------------------+
>> Mnemonic | Byte Offset | Byte Length | Description
>> |
>> -----------------+---------------+--------------+-------------------------------------------+
>> ........ | ............ | ......... | ...........
>> |
>> -----------------+---------------+--------------+-------------------------------------------+
>> Memory Error Type| 72 | 1 |Identifies the type of
>> error that occurred:|
>> | | | 0 – Unknown
>> |
>> | | | 1 – No error
>> |
>> | | | 2 – Single-bit ECC
>> |
>> | | | 3 – Multi-bit ECC
>> |
>> | | | 4 – Single-symbol ChipKill
>> ECC |
>> | | | 5 – Multi-symbol ChipKill
>> ECC |
>> | | | 6 – Master abort
>> |
>> | | | 7 – Target abort
>> |
>> | | | 8 – Parity Error
>> |
>> | | | 9 – Watchdog timeout
>> |
>> | | | 10 – Invalid address
>> |
>> | | | 11 – Mirror Broken
>> |
>> | | | 12 – Memory Sparing
>> |
>> | | | 13 - Scrub corrected error
>> |
>> | | | 14 - Scrub uncorrected
>> error |
>> | | | 15 - Physical Memory
>> Map-out event |
>> | | | All other values reserved.
>> |
>> -----------------+---------------+--------------+-------------------------------------------+
>> ........ | ............ | ......... | ...........
>> |
>> -----------------+---------------+--------------+-------------------------------------------+
> There's a value specified for "we don't know what the error type is",
> which is "0 - Unknown". I think we should use that rather than claiming
> that we have a particular type of error when we don't actually know that.
Agree peter's suggestion. It seems "0 - Unknown" makes sense.
>
> I agree with James that we don't want to report a particular type of
> error to the guest anyway -- the VM is a virtual environment, and
> the exact reason why the hardware/firmware/host kernel have decided
> that a bit of RAM isn't usable any more doesn't matter to the guest.
> We just want to report "this RAM has gone away, sorry" to it.
Agree with peter, appreciate for the comments.
>
> thanks
> -- PMM