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 10:18:56 +0200 Message-ID: <4FD063F0.3060301@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> <4FD05CED.60905@amd.com> <20120607080833.GA23186@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120607080833.GA23186@kroah.com> Sender: linux-kernel-owner@vger.kernel.org To: Greg KH Cc: Borislav Petkov , "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 10:08 AM, Greg KH wrote: > On Thu, Jun 07, 2012 at 09:49:01AM +0200, Andre Przywara wrote: >> 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. > > What? So I don't need to do anything? > > Totally confused, Sorry for that. To fix the issue, we need only one of those patches. Mine ("Fix crash as Xen Dom0 on AMD Trinity systems", removing "_amd" from the rd/wrmsr calls) was sent out earlier, so I added the stable tag. A bit later Konrad sent his patch (1ab46fd319bc, initializing the forgotten PVOPS members), which hpa took (dropping mine). So this fix is in 3.5-rc1 and should also be in -stable. Now for making things smoother Boris sent out mine again - for 3.6 - and more or less accidentally kept the stable tag in it. Long story short: everything is fine, just apply the one you sent the review message for. HTH, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany