[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120607072159.GB9856@aftab.osrc.amd.com>
Date: Thu, 7 Jun 2012 09:21:59 +0200
From: Borislav Petkov <bp@...64.org>
To: "H. Peter Anvin" <hpa@...or.com>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc: Borislav Petkov <bp@...64.org>, Jacob Shin <jacob.shin@....com>,
Andre Przywara <andre.przywara@....com>, jeremy@...p.org,
xen-devel@...ts.xensource.com, LKML <linux-kernel@...r.kernel.org>,
Jan Beulich <JBeulich@...e.com>,
Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Andreas Herrmann <andreas.herrmann3@....com>,
stable@...r.kernel.org
Subject: Re: [PATCH 3/4] x86, AMD: Fix crash as Xen Dom0 on AMD Trinity
systems
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 <andre.przywara@....com>
> >
> > 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 <andre.przywara@....com>
> > Cc: Andreas Herrmann <andreas.herrmann3@....com>
> > Cc: stable@...r.kernel.org # 3.4+
> > Link: <http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@amd.com>
> > [Boris: correct and expand commit message]
> > Signed-off-by: Borislav Petkov <borislav.petkov@....com>
>
> 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?
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?
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists