On Tuesday 17 March 2009 04:24:35 Jiang, Yunhong wrote:
> 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.
The featureset of AMD Athlon K7 and Intel Pentium III are the common
denominator on x86. This is what can go into the common code.
In order to utilize features from newer cpus, allow to register function
pointers and call them from the common code. Look into the amd_k8.c
and amd_f10.c for example code. I register a function pointer to read
the new MSRs. It can be easily extended to utilize features of coming CPUs.
> 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
--
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home