qemu-arm
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]