On Thu, Oct 19, 2017 at 03:58:05PM +0100, James Morse wrote:
> We expect to have firmware-first handling of RAS SErrors, with errors
> notified via an APEI method. For systems without firmware-first, add
> some minimal handling to KVM.
>
> There are two ways KVM can take an SError due to a guest,
On Thu, Oct 19 2017 at 4:58:05 pm BST, James Morse wrote:
> We expect to have firmware-first handling of RAS SErrors, with errors
> notified via an APEI method. For systems without firmware-first, add
> some minimal handling to KVM.
>
> There are two ways KVM can take an
Hi gengdongjiu,
On 27/10/17 07:26, gengdongjiu wrote:
> On 2017/10/19 22:58, James Morse wrote:
>> +alternative_if ARM64_HAS_RAS_EXTN
>> +// If we have the RAS extensions we can consume a pending error
>> +// without an unmask-SError and isb.
>> +esb
>> +mrs_s x2, SYS_DISR_EL1
On 2017/10/19 22:58, James Morse wrote:
> +alternative_if ARM64_HAS_RAS_EXTN
> + // If we have the RAS extensions we can consume a pending error
> + // without an unmask-SError and isb.
> + esb
> + mrs_s x2, SYS_DISR_EL1
I do not think you can get the right value when esb
We expect to have firmware-first handling of RAS SErrors, with errors
notified via an APEI method. For systems without firmware-first, add
some minimal handling to KVM.
There are two ways KVM can take an SError due to a guest, either may be a
RAS error: we exit the guest due to an SError routed