Xen devel - May 2010 - [PATCH] Fix for AMD erratum 383 on Family 10h CPUs

This patches implements the workaround of AMD erratum 383 on family 10h 
CPUs. It destroys the guest VM when a MC error with a special pattern is 
detected. Without this patch, a guest VM failure can potentially crash 
Xen hypervisor and the whole system. The erratum will be published in 
next version of guide.

Signed-off-by: Wei Huang <wei.huang2@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Christoph Egger <christoph.egger@amd.com>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> Wei Huang <wei.huang2@amd.com> 17.05.10 20:57 >>>
>This patches implements the workaround of AMD erratum 383 on family 10h 
>CPUs. It destroys the guest VM when a MC error with a special pattern is 
>detected. Without this patch, a guest VM failure can potentially crash 
>Xen hypervisor and the whole system. The erratum will be published in 
>next version of guide.
While I realize that the patch has already been applied, I still have
some reservations:
- It fiddles with bit 47 of MSR_AMD64_DC_CFG *and* marks that the
  erratum is present. Normally I would expect that MSR modifications
  are done to work around an erratum, but here it is completely
  unclear what the modification is good for.
- It clears all MCi_STATUS registers, despite (as I understand it) the
  problem only involving bank 0.
- It flushes the TLBs for the affected domain - shouldn''t this be done
  globally, if it is necessary at all?
- Is it guaranteed that the #MC cannot happen when a #VMEXIT is
  already being processed by the CPU?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel