From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH] Fix for AMD erratum 383 on Family 10h CPUs Date: Wed, 19 May 2010 12:55:16 +0100 Message-ID: <4BF3EDC4020000780000330F@vpn.id2.novell.com> References: <4BF19195.1080907@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4BF19195.1080907@amd.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Wei Huang Cc: joerg.roedel@amd.com, Christoph Egger , xen-devel@lists.xensource.com, Keir Fraser List-Id: xen-devel@lists.xenproject.org >>> Wei Huang 17.05.10 20:57 >>> >This patches implements the workaround of AMD erratum 383 on family = 10h=20 >CPUs. It destroys the guest VM when a MC error with a special pattern = is=20 >detected. Without this patch, a guest VM failure can potentially crash=20 >Xen hypervisor and the whole system. The erratum will be published in=20 >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