From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: [PATCH 3/4] x86, AMD: Fix crash as Xen Dom0 on AMD Trinity systems Date: Thu, 7 Jun 2012 09:49:01 +0200 Message-ID: <4FD05CED.60905@amd.com> References: <1338562358-28182-1-git-send-email-bp@amd64.org> <1338562358-28182-4-git-send-email-bp@amd64.org> <4FCFD2EE.8060508@zytor.com> <20120607072159.GB9856@aftab.osrc.amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120607072159.GB9856@aftab.osrc.amd.com> Sender: linux-kernel-owner@vger.kernel.org To: Borislav Petkov Cc: "H. Peter Anvin" , Konrad Rzeszutek Wilk , Jacob Shin , jeremy@goop.org, xen-devel@lists.xensource.com, LKML , Jan Beulich , Ingo Molnar , Thomas Gleixner , Andreas Herrmann , stable@vger.kernel.org List-Id: xen-devel@lists.xenproject.org On 06/07/2012 09:21 AM, Borislav Petkov wrote: > On Wed, Jun 06, 2012 at 03:00:14PM -0700, H. Peter Anvin wrote: >> On 06/01/2012 07:52 AM, Borislav Petkov wrote: >>> From: Andre Przywara >>> >>> f7f286a910221 ("x86/amd: Re-enable CPU topology extensions in case BIOS >>> has disabled it") wrongfully added code which used the AMD-specific >>> {rd,wr}msr variants for no real reason. >>> >>> This caused boot panics on xen which wasn't initializing the >>> {rd,wr}msr_safe_regs pv_ops members properly. >>> >>> This, in turn, caused a heated discussion leading to us reviewing all >>> uses of the AMD-specific variants and removing them where unneeded >>> (almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358). >>> >>> Finally, this patch switches to the standard {rd,wr}msr*_safe* variants >>> which should've been used in the first place anyway and avoided unneeded >>> excitation with xen. >>> >>> Signed-off-by: Andre Przywara >>> Cc: Andreas Herrmann >>> Cc: stable@vger.kernel.org # 3.4+ >>> Link: >>> [Boris: correct and expand commit message] >>> Signed-off-by: Borislav Petkov >> >> Why -stable? I though we had agreed that we didn't have an active >> problem (unclean hack, yes, but not an active problem) in 3.4/3.5 as it >> currently sits? This is probably a leftover from the original patch, before Konrad's patch got committed. > Yes, AFAICT, we need at least one fix for 3.4 where the original patch > f7f286a910221 broke xen. > > So either this one or 1ab46fd319bc should be backported to stable, if > I'm not mistaken. If the second, I'll drop the stable tag from this one > and resend. > > Konrad, what do you want wrt xen paravirt nullptr breakage for > 3.4-stable? Greg just sent out the review mail for 1ab46fd319bc, so we can drop the stable tag from this one. Regards, Andre. -------- Original Message -------- Subject: [ 21/82] x86, amd, xen: Avoid NULL pointer paravirt references Date: Thu, 7 Jun 2012 13:03:57 +0900 From: Greg KH To: , CC: , , , Andre Przywara , "H. Peter Anvin" 3.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Konrad Rzeszutek Wilk commit 1ab46fd319bcf1fcd9fb6311727d532b580e4eba upstream. Stub out MSR methods that aren't actually needed. This fixes a crash as Xen Dom0 on AMD Trinity systems. A bigger patch should be added to remove the paravirt machinery completely for the methods which apparently have no users! ..... -- Andre Przywara AMD-OSRC (Dresden) Tel: x29712