xen-devel-bounces@xxxxxxxxxxxxxxxxxxx <> wrote:
> The following patch reworks the MCA error telemetry handling
> inside Xen,
> and shares code between the Intel and AMD implementations as much as
> possible.
>
> I've had this patch sitting around for a while, but it wasn't
> ported to
> -unstable yet. I finished porting and testing it, and am submitting it
> now, because the Intel folks want to go ahead and submit their new
> changes, so we agreed that I should push our changes first.
>
> Brief explanation of the telemetry part: previously, the telemetry was
> accessed in a global array, with index variables used to access it.
> There were some issues with that: race conditions with regard to new
> machine checks (or CMCIs) coming in while handling the telemetry, and
> interaction with domains having been notified or not, which was a bit
> hairy. Our changes (I should say: Gavin Maltby's changes, as
> he did the
> bulk of this work for our 3.1 based tree, I merely
> ported/extended it to
> 3.3 and beyond) make telemetry access transactional (think of a
> database). Also, the internal database updates are atomic, since the
> final commit is done by a pointer swap. There is a brief
> explanation of
> the mechanism in mctelem.h.This patch also removes dom0->domU
> notification, which is ok, since Intel's upcoming changes will replace
> domU notification with a vMCE mechanism anyway.
>
> The common code part is pretty much what it says. It defines a common
> MCE handler, with a few hooks for the special needs of the
> specific CPUs.
>
> I've been told that Intel's upcoming patch will need to make
> some parts
> of the common code specific to the Intel CPU again, but we'll work
> together to use as much common code as possible.
Yes, as shown in our previous patch, we do change the current MCA handler, the
main changes are followed:
1) Most importantly, we implement a softIRQ mechanism for post MCE handler.
The reason is, the #MC can happen in any time, that means: Firstly it
is spin-lock unsafe, some code like vcpu_schedule_lock_irq(v) in current MCA
handler is sure to cause hang if that lock is already hold by a ISR; Secondly,
the execution context is uncertain, the "current " value in current MCA handler
maybe incorrect (if set_current is interrupted by #MC), the page ownership
maybe wrong (if still in change under heap_lock protection) etc. I remember
this
So our patch handling #MC is in two step. The MCA handler, which
depends on the execution context when MCA happen (like checking if it is in Xen
context) and especially it will bring all CPU to softIRQ context. The softIRQ
handler (i.e. post handler), which will be spin_lock safe, and all CPU is
redenzvous, so it can take more actions.
2) We implement a mechanism to handle the shared MSR resources similar to what
we have done in CMCI handler. As the Intel SDM stated, some MC resource is
shared by multiple logical CPU, we implement a ownership check.
3) As stated in linux MCA handler, on Intel platforms machine check exceptions
are always broadcast to all CPUs, we add such support also.
We have no idea how the issues for item 2 and 3 are handled on other platform,
so we have no idea on how to do the common handler for it, hope Christoph can
provide more suggestion, or we can just keep them different for different
platform.
But I think for item 1, it is software related, so it can be a enhancement to
the common handler, the only thing I'm not sure is, if we need bring all CPU to
softIRQ context in all platform, maybe Christoph can give more idea.
Since we have get most consensus on the high level idea of MCA handler (i.e.
Xen take action instead of dom0, use vMCE for guest MCA etc, check discussion
with subject " [RFC] RAS(Part II)--MCA enalbing in XEN", the only thing left is
the detail method of how to pass the recover action information to dom0), maybe
we can turn to this second level discussion of how to enhance the (common) MCA
handler.
Thanks
-- Yunhong Jiang
>
> - Frank
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home