This DOC is a brief description about the series of patches for MCA enabling in XEN

With the new availability of hardware MCA support in newly x86 Platform as well as the increasing
software demands, we're doing MCA enhancement jobs for XEN upstream. The corrected
error handling (CMCI) part is now in upstream. This doc focuses on the uncorrected error handling.
Current XEN upstream MCA support is checked in by Christoph which already did much
great improvements. Most of our MCA jobs are based on it.

Our Target:
1) Narrow MCE# impact. Try to keep the system/guest working running as much as possible.
2) Log information in DOM0 as much as possible.

Diffs with current implementation:
When enabling MCA Intel platform, we also made some changes including:
1) Xen will handle the MCA, i.e. Xen will decide impacted components, take recover action, 
   inject virtual MCA to guest etc. Especially, Xen will directly inject vMCE# to the impacted DOM 
   to avoid current notification from DOM0 to DOMU.
2) Xen will provide MCA MSR virtualization so that guest's native #MC handler can run without changes. 
   With this method, we can benifit from guest #MC handler enhancement and no need to maintain PV MCA 
   handler. See http://lists.xensource.com/archives/html/xen-devel/2008-12/msg00643.html for more 
   information on how to support guest MCA. 
3) We add MCE owner judgement algorithm in XEN MCE# handler since some MCA banks are shared among CPUs.
4) Adopt two round banks scanning, reset system when meeting fatal/non-recoverable errors without clearing 
   the MCA MSR, so that the MCA information will be logged after reboot.

Some detailed notes for MCA handling:
1)  When MCE# happens, if the error is fatal (pcc=1) or can't be recovered, for avoiding losing LOGS in
     DOM0 as much as possible, we will reset machine since MSRs banks are sticky. After reboot, MCA polling
     mechanism will be responsible for LOG. So we adopt two round banks scanning.
2)  When MCE# happens, all CPUs enter MCA context. The first CPU who read&clear the error MSR bank will be this
     MCE# owner. Necessary locks/synchronization will help to judge the owner and select most severe error.
3)  XEN's MCA MSR virtualization will provide MCA MSR virtualization to guest for reuse guest native handler. 
    Currently, we only virtualize MSR read/write. 
4)  MCE# happens, we will do following jobs:
    a. Send vIRQ to DOM0 for logging. Log as complete as possible.
    b. Send vMCE# to Impacted Guest (Currently we do injection only if impacted guest is Dom0)
    c. Guest vMCE MSR virtualization
    d. Recovery action in XEN (offline offending page).

MCE# processing Sequence Flow for your reference:
1)  MCE# happens and invoke XEN MCE# handler.
2)  XEN MCE# handler judges the severity and the impacted domain, decides whether to reset whole system 
    or be able to do some recovery.
3)  If error can be recovered, send vIRQ to DOM0 for logging, send vMCE# to impacted Guest 
    (Currently we only inject to DOM0),  and continue recovery action.
4)  Guest MCA handler will be invoked after receiving the injected vMCE#. Guest MCA# MSR banks read/write 
    will be traped by HV(vMCE# MSR virtualization).