MCE in pv-domU

MCE in pv-domU

[Juergen Gross]

Just saw the message:

[    0.005227] mce: CPU supports 2 MCE banks

in the boot log of a pv domU (Linux 4.11). I really have problems to see
the value of MCE handling being active in this case. Shouldn't we switch
it off?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: MCE in pv-domU

[Jan Beulich]

>>> On 07.06.17 at 16:00, <jgross@suse.com> wrote:
> Just saw the message:
> 
> [    0.005227] mce: CPU supports 2 MCE banks
> 
> in the boot log of a pv domU (Linux 4.11). I really have problems to see
> the value of MCE handling being active in this case. Shouldn't we switch
> it off?

What's wrong with letting a guest decide on its own what to do
if a memory page assigned to it went bad? From host perspective
the only "recovery" would be to kill the guest. The guest kernel,
otoh, may be able to confine damage to just the killing of a single
process (or if the page is not in use, no damage would result at
all).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: MCE in pv-domU

[Juergen Gross]

On 07/06/17 16:10, Jan Beulich wrote:
>>>> On 07.06.17 at 16:00, <jgross@suse.com> wrote:
>> Just saw the message:
>>
>> [    0.005227] mce: CPU supports 2 MCE banks
>>
>> in the boot log of a pv domU (Linux 4.11). I really have problems to see
>> the value of MCE handling being active in this case. Shouldn't we switch
>> it off?
> 
> What's wrong with letting a guest decide on its own what to do
> if a memory page assigned to it went bad? From host perspective
> the only "recovery" would be to kill the guest. The guest kernel,
> otoh, may be able to confine damage to just the killing of a single
> process (or if the page is not in use, no damage would result at
> all).

So the MCE related resources are fully virtualized for the guest?


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: MCE in pv-domU

[Jan Beulich]

>>> On 07.06.17 at 16:23, <jgross@suse.com> wrote:
> On 07/06/17 16:10, Jan Beulich wrote:
>>>>> On 07.06.17 at 16:00, <jgross@suse.com> wrote:
>>> Just saw the message:
>>>
>>> [    0.005227] mce: CPU supports 2 MCE banks
>>>
>>> in the boot log of a pv domU (Linux 4.11). I really have problems to see
>>> the value of MCE handling being active in this case. Shouldn't we switch
>>> it off?
>> 
>> What's wrong with letting a guest decide on its own what to do
>> if a memory page assigned to it went bad? From host perspective
>> the only "recovery" would be to kill the guest. The guest kernel,
>> otoh, may be able to confine damage to just the killing of a single
>> process (or if the page is not in use, no damage would result at
>> all).
> 
> So the MCE related resources are fully virtualized for the guest?

For some to be established definition of "fully", yes (IOW that's
the intention, but I'd be surprised if there were no missing pieces
at all).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: MCE in pv-domU

[Andrew Cooper]

On 07/06/17 15:31, Jan Beulich wrote:
>>>> On 07.06.17 at 16:23, <jgross@suse.com> wrote:
>> On 07/06/17 16:10, Jan Beulich wrote:
>>>>>> On 07.06.17 at 16:00, <jgross@suse.com> wrote:
>>>> Just saw the message:
>>>>
>>>> [    0.005227] mce: CPU supports 2 MCE banks
>>>>
>>>> in the boot log of a pv domU (Linux 4.11). I really have problems to see
>>>> the value of MCE handling being active in this case. Shouldn't we switch
>>>> it off?
>>> What's wrong with letting a guest decide on its own what to do
>>> if a memory page assigned to it went bad? From host perspective
>>> the only "recovery" would be to kill the guest. The guest kernel,
>>> otoh, may be able to confine damage to just the killing of a single
>>> process (or if the page is not in use, no damage would result at
>>> all).
>> So the MCE related resources are fully virtualized for the guest?
> For some to be established definition of "fully", yes (IOW that's
> the intention, but I'd be surprised if there were no missing pieces
> at all).

For reasons known to the original authors of the code, CR4.MCE is
deliberately visible (but not modifiable) to PV guests.

Beyond that, it is the default leaking of all MSRs into guests (See the
default case in priv_op_read_msr()) which is presumably what allows this
domU to find 2 banks.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel