On Thursday 19 November 2015 07:26 AM, Alexey Kardashevskiy wrote:
> On 11/13/2015 05:23 AM, Aravinda Prasad wrote:
>
+
+/*
+ * Currently KVM only passes on the uncorrected machine
+ * check memory error to guest. Other machine check errors
+ * such as SLB multi-hit and
On 11/13/2015 05:23 AM, Aravinda Prasad wrote:
+
+/*
+ * Currently KVM only passes on the uncorrected machine
+ * check memory error to guest. Other machine check errors
+ * such as SLB multi-hit and TLB multi-hit are recovered
+ * in KVM and are not passed on to guest.
+ *
+ * DSISR Bit for unc
On Mon, Nov 16, 2015 at 10:01:25AM +0100, Thomas Huth wrote:
> On 16/11/15 04:50, Paul Mackerras wrote:
> > On Thu, Nov 12, 2015 at 09:09:59AM +0100, Thomas Huth wrote:
> >>
> >> Shouldn't you also check MSR_ME here first and enter checkstop when
> >> machine checks are disabled?
> >
> > MSR_ME is
On Monday 16 November 2015 02:31 PM, Thomas Huth wrote:
> On 16/11/15 04:50, Paul Mackerras wrote:
>> On Thu, Nov 12, 2015 at 09:09:59AM +0100, Thomas Huth wrote:
>>>
>>> Shouldn't you also check MSR_ME here first and enter checkstop when
>>> machine checks are disabled?
>>
>> MSR_ME is a hypervi
On 16/11/15 11:07, Aravinda Prasad wrote:
>
>
> On Monday 16 November 2015 01:22 PM, Thomas Huth wrote:
>> On 12/11/15 19:49, Aravinda Prasad wrote:
>>>
>>> On Thursday 12 November 2015 03:10 PM, Thomas Huth wrote:
>> ...
Also LoPAPR talks about 'subsequent processors report "fatal error
>>>
On Monday 16 November 2015 04:11 PM, Thomas Huth wrote:
> On 16/11/15 11:07, Aravinda Prasad wrote:
>>
>>
>> On Monday 16 November 2015 01:22 PM, Thomas Huth wrote:
>>> On 12/11/15 19:49, Aravinda Prasad wrote:
On Thursday 12 November 2015 03:10 PM, Thomas Huth wrote:
>>> ...
> Also
On Fri, Nov 13, 2015 at 08:03:51AM +0100, Thomas Huth wrote:
> On 13/11/15 02:57, David Gibson wrote:
> > On Thu, Nov 12, 2015 at 10:40:11AM +0100, Thomas Huth wrote:
> >> On 12/11/15 09:09, Thomas Huth wrote:
> >>> On 11/11/15 18:16, Aravinda Prasad wrote:
> [...]
> +qemu_mutex_lock(&spap
On 12/11/15 19:49, Aravinda Prasad wrote:
>
> On Thursday 12 November 2015 03:10 PM, Thomas Huth wrote:
...
>> Also LoPAPR talks about 'subsequent processors report "fatal error
>> previously reported"', so maybe the other processors should report that
>> condition in this case?
>
> I feel guest
On Thu, Nov 12, 2015 at 09:09:59AM +0100, Thomas Huth wrote:
>
> Shouldn't you also check MSR_ME here first and enter checkstop when
> machine checks are disabled?
MSR_ME is a hypervisor resource and is not able to be controlled by HV
KVM guests, or in fact by the OS running on the pseries machin
On 16/11/15 04:50, Paul Mackerras wrote:
> On Thu, Nov 12, 2015 at 09:09:59AM +0100, Thomas Huth wrote:
>>
>> Shouldn't you also check MSR_ME here first and enter checkstop when
>> machine checks are disabled?
>
> MSR_ME is a hypervisor resource and is not able to be controlled by HV
> KVM guests,
On Monday 16 November 2015 01:22 PM, Thomas Huth wrote:
> On 12/11/15 19:49, Aravinda Prasad wrote:
>>
>> On Thursday 12 November 2015 03:10 PM, Thomas Huth wrote:
> ...
>>> Also LoPAPR talks about 'subsequent processors report "fatal error
>>> previously reported"', so maybe the other processors
On 13/11/15 02:57, David Gibson wrote:
> On Thu, Nov 12, 2015 at 10:40:11AM +0100, Thomas Huth wrote:
>> On 12/11/15 09:09, Thomas Huth wrote:
>>> On 11/11/15 18:16, Aravinda Prasad wrote:
[...]
+qemu_mutex_lock(&spapr->mc_in_progress);
>>>
>>> Using a mutex here is definitely wrong. The k
On Friday 13 November 2015 11:27 AM, David Gibson wrote:
> On Fri, Nov 13, 2015 at 10:23:20AM +0530, Aravinda Prasad wrote:
>>
>>
>> On Friday 13 November 2015 07:28 AM, David Gibson wrote:
>>> On Thu, Nov 12, 2015 at 11:53:45PM +0530, Aravinda Prasad wrote:
On Thursday 12 November
On Fri, Nov 13, 2015 at 10:23:20AM +0530, Aravinda Prasad wrote:
>
>
> On Friday 13 November 2015 07:28 AM, David Gibson wrote:
> > On Thu, Nov 12, 2015 at 11:53:45PM +0530, Aravinda Prasad wrote:
> >>
> >>
> >> On Thursday 12 November 2015 01:39 PM, Thomas Huth wrote:
> >>> On 11/11/15 18:16, Ar
On Friday 13 November 2015 07:28 AM, David Gibson wrote:
> On Thu, Nov 12, 2015 at 11:53:45PM +0530, Aravinda Prasad wrote:
>>
>>
>> On Thursday 12 November 2015 01:39 PM, Thomas Huth wrote:
>>> On 11/11/15 18:16, Aravinda Prasad wrote:
Memory error such as bit flips that cannot be corrected
On Thu, Nov 12, 2015 at 11:53:45PM +0530, Aravinda Prasad wrote:
>
>
> On Thursday 12 November 2015 01:39 PM, Thomas Huth wrote:
> > On 11/11/15 18:16, Aravinda Prasad wrote:
> >> Memory error such as bit flips that cannot be corrected
> >> by hardware are passed on to the kernel for handling.
>
On Thu, Nov 12, 2015 at 10:40:11AM +0100, Thomas Huth wrote:
> On 12/11/15 09:09, Thomas Huth wrote:
> > On 11/11/15 18:16, Aravinda Prasad wrote:
> >> Memory error such as bit flips that cannot be corrected
> >> by hardware are passed on to the kernel for handling.
> >> If the memory address in er
On Thursday 12 November 2015 03:10 PM, Thomas Huth wrote:
> On 12/11/15 09:09, Thomas Huth wrote:
>> On 11/11/15 18:16, Aravinda Prasad wrote:
>>> Memory error such as bit flips that cannot be corrected
>>> by hardware are passed on to the kernel for handling.
>>> If the memory address in error b
On Thursday 12 November 2015 01:39 PM, Thomas Huth wrote:
> On 11/11/15 18:16, Aravinda Prasad wrote:
>> Memory error such as bit flips that cannot be corrected
>> by hardware are passed on to the kernel for handling.
>> If the memory address in error belongs to guest then
>> guest kernel is resp
On 12/11/15 09:09, Thomas Huth wrote:
> On 11/11/15 18:16, Aravinda Prasad wrote:
>> Memory error such as bit flips that cannot be corrected
>> by hardware are passed on to the kernel for handling.
>> If the memory address in error belongs to guest then
>> guest kernel is responsible for taking sui
On 11/11/15 18:16, Aravinda Prasad wrote:
> Memory error such as bit flips that cannot be corrected
> by hardware are passed on to the kernel for handling.
> If the memory address in error belongs to guest then
> guest kernel is responsible for taking suitable action.
> Patch [1] enhances KVM to ex
On Thursday 12 November 2015 09:59 AM, David Gibson wrote:
> On Wed, Nov 11, 2015 at 10:46:02PM +0530, Aravinda Prasad wrote:
>> Memory error such as bit flips that cannot be corrected
>> by hardware are passed on to the kernel for handling.
>> If the memory address in error belongs to guest then
On Wed, Nov 11, 2015 at 10:46:02PM +0530, Aravinda Prasad wrote:
> Memory error such as bit flips that cannot be corrected
> by hardware are passed on to the kernel for handling.
> If the memory address in error belongs to guest then
> guest kernel is responsible for taking suitable action.
> Patch
Memory error such as bit flips that cannot be corrected
by hardware are passed on to the kernel for handling.
If the memory address in error belongs to guest then
guest kernel is responsible for taking suitable action.
Patch [1] enhances KVM to exit guest with exit reason
set to KVM_EXIT_NMI in suc
24 matches
Mail list logo
