[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH 3/4] x86, AMD: Fix crash as Xen Dom0 on AMD Trinity systems
- To: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- From: Andre Przywara <andre.przywara@xxxxxxx>
- Date: Thu, 7 Jun 2012 10:18:56 +0200
- Cc: jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Andreas Herrmann <andreas.herrmann3@xxxxxxx>, Jacob Shin <jacob.shin@xxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, stable@xxxxxxxxxxxxxxx, Jan Beulich <JBeulich@xxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>
- Delivery-date: Thu, 07 Jun 2012 08:20:04 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.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<andre.przywara@xxxxxxx>
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@xxxxxxx>
Cc: Andreas Herrmann<andreas.herrmann3@xxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx # 3.4+
Link:<http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przywara@xxxxxxx>
[Boris: correct and expand commit message]
Signed-off-by: Borislav Petkov<borislav.petkov@xxxxxxx>
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|