Re: [Xen-devel] [PATCH 2/2] Xen/vMCE: bugfix to remove problematic is_vmce_ready check

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.04.13 at 10:38, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
> From 9098666db640183f894b9aec09599dd32dddb7fa Mon Sep 17 00:00:00 2001
> From: Liu Jinsong <jinsong.liu@xxxxxxxxx>
> Date: Sat, 27 Apr 2013 22:37:35 +0800
> Subject: [PATCH 2/2] Xen/vMCE: bugfix to remove problematic is_vmce_ready 
> check
> 
> is_vmce_ready() is problematic:
> * For dom0, it checks if virq bind to dom0 mcelog driver. If not, it
> results dom0 crash. However, it's problematic and overkilled since
> mcelog as a dom0 feature could be enabled/disabled per dom0 option:
> (XEN) MCE: This error page is ownded by DOM 0
> (XEN) DOM0 not ready for vMCE
> (XEN) domain_crash called from mcaction.c:133
> (XEN) Domain 0 reported crashed by domain 32767 on cpu#31:
> (XEN) Domain 0 crashed: rebooting machine in 5 seconds.
> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
> 
> * For dom0, if really need check, it should check whether vMCE
> injection for dom0 ready (say, exception trap bounce check, which
> has been done at inject_vmce()), not check dom0 mcelog ready (which
> has been done at mce_softirq() before send global virq to dom0).

Following the argumentation above, I wonder which of the other
"goto vmce_failed" are really appropriate, i.e. whether the patch
shouldn't be extended (at least for the Dom0 case).

Jan

> * For hvm, it checks whether guest vcpu has different virtual
> family/model with that of host pcpu --> that's deprecated, since
> vMCE has changed a lot, not bound to host MCE any more.




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