On 2017/10/7 1:31, James Morse wrote:
> Hi gengdongjiu,
>
> On 27/09/17 12:07, gengdongjiu wrote:
>> On 2017/9/23 0:51, James Morse wrote:
>>> If this wasn't a firmware-first notification, then you're right KVM hands
>>> the
>>> guest an asynchronous external abort. This could be considered a
On 2017/10/7 1:31, James Morse wrote:
> Hi gengdongjiu,
>
> On 27/09/17 12:07, gengdongjiu wrote:
>> On 2017/9/23 0:51, James Morse wrote:
>>> If this wasn't a firmware-first notification, then you're right KVM hands
>>> the
>>> guest an asynchronous external abort. This could be considered a
Hi gengdongjiu,
On 27/09/17 12:07, gengdongjiu wrote:
> On 2017/9/23 0:51, James Morse wrote:
>> If this wasn't a firmware-first notification, then you're right KVM hands the
>> guest an asynchronous external abort. This could be considered a bug in KVM.
>> (we
>> can discuss with Marc and
Hi gengdongjiu,
On 27/09/17 12:07, gengdongjiu wrote:
> On 2017/9/23 0:51, James Morse wrote:
>> If this wasn't a firmware-first notification, then you're right KVM hands the
>> guest an asynchronous external abort. This could be considered a bug in KVM.
>> (we
>> can discuss with Marc and
>> What you may be seeing is some awkwardness with the change in the SError ESR
>> with v8.2. Previously the VSE mechanism injected an impdef SError, (but they
>> were all impdef so it didn't matter).
>> With VSESR_EL2 KVM has to specify one, and all-zeros is a bad choice as this
>> means
>> What you may be seeing is some awkwardness with the change in the SError ESR
>> with v8.2. Previously the VSE mechanism injected an impdef SError, (but they
>> were all impdef so it didn't matter).
>> With VSESR_EL2 KVM has to specify one, and all-zeros is a bad choice as this
>> means
Hi James,
Sorry for my late response, thank you very much for comments.
On 2017/9/23 0:51, James Morse wrote:
[.]
>>
>> CC Achin
>>
>> I have some personal opinion, if you think it is not right, hope you can
>> point out.
>>
>> Synchronous External Abort and SError Interrupt are hardware
Hi James,
Sorry for my late response, thank you very much for comments.
On 2017/9/23 0:51, James Morse wrote:
[.]
>>
>> CC Achin
>>
>> I have some personal opinion, if you think it is not right, hope you can
>> point out.
>>
>> Synchronous External Abort and SError Interrupt are hardware
Hi gengdongjiu,
On 21/09/17 08:55, gengdongjiu wrote:
> On 2017/9/14 21:00, James Morse wrote:
>> user-space can choose whether to use SEA or SEI, it doesn't have to choose
>> the
>> same notification type that firmware used, which in turn doesn't have to be
>> the
>> same as that used by the
Hi gengdongjiu,
On 21/09/17 08:55, gengdongjiu wrote:
> On 2017/9/14 21:00, James Morse wrote:
>> user-space can choose whether to use SEA or SEI, it doesn't have to choose
>> the
>> same notification type that firmware used, which in turn doesn't have to be
>> the
>> same as that used by the
Hi gengdongjiu,
On 18/09/17 14:36, gengdongjiu wrote:
> On 2017/9/14 21:00, James Morse wrote:
>> On 13/09/17 08:32, gengdongjiu wrote:
>>> On 2017/9/8 0:30, James Morse wrote:
On 28/08/17 11:38, Dongjiu Geng wrote:
For BUS_MCEERR_A* from memory_failure() we can't know if they are
Hi gengdongjiu,
On 18/09/17 14:36, gengdongjiu wrote:
> On 2017/9/14 21:00, James Morse wrote:
>> On 13/09/17 08:32, gengdongjiu wrote:
>>> On 2017/9/8 0:30, James Morse wrote:
On 28/08/17 11:38, Dongjiu Geng wrote:
For BUS_MCEERR_A* from memory_failure() we can't know if they are
Hi James
On 2017/9/14 21:00, James Morse wrote:
> Hi gengdongjiu,
> user-space can choose whether to use SEA or SEI, it doesn't have to choose the
> same notification type that firmware used, which in turn doesn't have to be
> the
> same as that used by the CPU to notify firmware.
>
> The
Hi James
On 2017/9/14 21:00, James Morse wrote:
> Hi gengdongjiu,
> user-space can choose whether to use SEA or SEI, it doesn't have to choose the
> same notification type that firmware used, which in turn doesn't have to be
> the
> same as that used by the CPU to notify firmware.
>
> The
James，
Thanks for your comments, hope we can make the solution better.
On 2017/9/14 21:00, James Morse wrote:
> Hi gengdongjiu,
>
> (re-ordered hunks)
>
> On 13/09/17 08:32, gengdongjiu wrote:
>> On 2017/9/8 0:30, James Morse wrote:
>>> On 28/08/17 11:38, Dongjiu Geng wrote:
>>> For
James，
Thanks for your comments, hope we can make the solution better.
On 2017/9/14 21:00, James Morse wrote:
> Hi gengdongjiu,
>
> (re-ordered hunks)
>
> On 13/09/17 08:32, gengdongjiu wrote:
>> On 2017/9/8 0:30, James Morse wrote:
>>> On 28/08/17 11:38, Dongjiu Geng wrote:
>>> For
Hi gengdongjiu,
(re-ordered hunks)
On 13/09/17 08:32, gengdongjiu wrote:
> On 2017/9/8 0:30, James Morse wrote:
>> On 28/08/17 11:38, Dongjiu Geng wrote:
>> For BUS_MCEERR_A* from memory_failure() we can't know if they are caused by
>> an access or not.
Actually it looks like we can: I thought
Hi gengdongjiu,
(re-ordered hunks)
On 13/09/17 08:32, gengdongjiu wrote:
> On 2017/9/8 0:30, James Morse wrote:
>> On 28/08/17 11:38, Dongjiu Geng wrote:
>> For BUS_MCEERR_A* from memory_failure() we can't know if they are caused by
>> an access or not.
Actually it looks like we can: I thought
Hi James,
On 2017/9/8 0:30, James Morse wrote:
> Hi Dongjiu Geng,
>
> On 28/08/17 11:38, Dongjiu Geng wrote:
>> when userspace gets SIGBUS signal, it does not know whether
>> this is a synchronous external abort or SError,
>
> Why would Qemu/kvmtool need to know if the original notification
Hi James,
On 2017/9/8 0:30, James Morse wrote:
> Hi Dongjiu Geng,
>
> On 28/08/17 11:38, Dongjiu Geng wrote:
>> when userspace gets SIGBUS signal, it does not know whether
>> this is a synchronous external abort or SError,
>
> Why would Qemu/kvmtool need to know if the original notification
Hi Dongjiu Geng,
On 28/08/17 11:38, Dongjiu Geng wrote:
> when userspace gets SIGBUS signal, it does not know whether
> this is a synchronous external abort or SError,
Why would Qemu/kvmtool need to know if the original notification (if there was
one) was synchronous or asynchronous? This is
Hi Dongjiu Geng,
On 28/08/17 11:38, Dongjiu Geng wrote:
> when userspace gets SIGBUS signal, it does not know whether
> this is a synchronous external abort or SError,
Why would Qemu/kvmtool need to know if the original notification (if there was
one) was synchronous or asynchronous? This is
when userspace gets SIGBUS signal, it does not know whether
this is a synchronous external abort or SError, so needs
to get the exception syndrome. This patch allows userspace
can get this values. For syndrome, only give userspace
syndrome EC and ISS.
Now we move the synchronous external abort
when userspace gets SIGBUS signal, it does not know whether
this is a synchronous external abort or SError, so needs
to get the exception syndrome. This patch allows userspace
can get this values. For syndrome, only give userspace
syndrome EC and ISS.
Now we move the synchronous external abort
24 matches
Mail list logo
