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 b
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 Christ
>> 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 'classifi
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 CP
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 caused
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 choic
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 BUS_MCEER
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 (if
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 betw
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 inj
12 matches
Mail list logo
