[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 4/5] x86: Port the basic alternative mechanism from Linux to Xen



>>> "Wu, Feng" <feng.wu@xxxxxxxxx> 05/30/14 6:48 AM >>>
> From: Andrew Cooper [mailto:amc96@xxxxxxxxxxxxxxxx] On Behalf Of
> Andrew Cooper
>> One option would be to temporarily disable it in cr4 at the same point
>> that NMIs are nopped out, in the same way as temporarily disabling
>> CR4.SMAP when building dom0.
>> 
>> At the end of the day, an MCE will certainly result in a crash, but at
>> least it wouldn't be from a weird fault because some of the codepath in
>> the MCE handler was midway through being patched.
>
>From the original comments below, which is from Linux:
>
        >/*
         >* Don't stop machine check exceptions while patching.
         >* MCEs only happen when something got corrupted and in this
         >* case we must do something about the corruption.
         >* Ignoring it is worse than a unlikely patching race.
         >* Also machine checks tend to be broadcast and if one CPU
         >* goes into machine check the others follow quickly, so we don't
         >* expect a machine check to cause undue problems during to code
         >* patching.
         >*/
>
>We can see that the MCE remains enabled here on purpose. It says
> "Ignoring the MCE is worse than a _unlikely_ patching race."
>Do you think we still need to disable MCE, or should we follow the
> current solution in Linux?

FWIW I can see downsides to both approaches, and hence would tend
towards following the original (Linux) route here despite the broadcasting
aspect mentioned above being IIRC an Intel specific, i.e. more of a
problem on AMD systems.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.