From: Andre Przywara <andre.przywara@amd.com>
To: Borislav Petkov <bp@amd64.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Jacob Shin <jacob.shin@amd.com>, <jeremy@goop.org>,
<xen-devel@lists.xensource.com>,
LKML <linux-kernel@vger.kernel.org>,
Jan Beulich <JBeulich@suse.com>, Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Andreas Herrmann <andreas.herrmann3@amd.com>,
<stable@vger.kernel.org>
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 [thread overview]
Message-ID: <4FD05CED.60905@amd.com> (raw)
In-Reply-To: <20120607072159.GB9856@aftab.osrc.amd.com>
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@amd.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@amd.com>
>>> Cc: Andreas Herrmann<andreas.herrmann3@amd.com>
>>> Cc: stable@vger.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@amd.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?
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 <gregkh@linuxfoundation.org>
To: <linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>
CC: <torvalds@linux-foundation.org>, <akpm@linux-foundation.org>,
<alan@lxorguk.ukuu.org.uk>, Andre Przywara <andre.przywara@amd.com>, "H.
Peter Anvin" <hpa@zytor.com>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
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
WARNING: multiple messages have this Message-ID (diff)
From: Andre Przywara <andre.przywara@amd.com>
To: Borislav Petkov <bp@amd64.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Jacob Shin <jacob.shin@amd.com>,
jeremy@goop.org, xen-devel@lists.xensource.com,
LKML <linux-kernel@vger.kernel.org>,
Jan Beulich <JBeulich@suse.com>, Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Andreas Herrmann <andreas.herrmann3@amd.com>,
stable@vger.kernel.org
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 [thread overview]
Message-ID: <4FD05CED.60905@amd.com> (raw)
In-Reply-To: <20120607072159.GB9856@aftab.osrc.amd.com>
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@amd.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@amd.com>
>>> Cc: Andreas Herrmann<andreas.herrmann3@amd.com>
>>> Cc: stable@vger.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@amd.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?
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 <gregkh@linuxfoundation.org>
To: <linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>
CC: <torvalds@linux-foundation.org>, <akpm@linux-foundation.org>,
<alan@lxorguk.ukuu.org.uk>, Andre Przywara <andre.przywara@amd.com>, "H.
Peter Anvin" <hpa@zytor.com>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
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
next prev parent reply other threads:[~2012-06-07 7:49 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-01 14:52 [PATCH 0/4] x86, CPU, AMD: Cleanup AMD-specific MSR-rw users Borislav Petkov
2012-06-01 14:52 ` [PATCH 1/4] x86, pvops: Remove hooks for {rd, wr}msr_safe_regs Borislav Petkov
2012-06-06 20:06 ` [PATCH 1/4] x86, pvops: Remove hooks for {rd,wr}msr_safe_regs Konrad Rzeszutek Wilk
2012-06-07 21:58 ` [tip:x86/cpu] " tip-bot for Andre Przywara
2012-06-01 14:52 ` [PATCH 2/4] x86, CPU: Fix show_msr MSR accessing function Borislav Petkov
2012-06-01 18:22 ` Yinghai Lu
2012-06-01 22:50 ` Borislav Petkov
2012-06-01 22:50 ` Borislav Petkov
2012-06-06 20:07 ` Konrad Rzeszutek Wilk
2012-06-07 21:59 ` [tip:x86/cpu] x86, cpu: " tip-bot for Borislav Petkov
2012-06-01 14:52 ` [PATCH 3/4] x86, AMD: Fix crash as Xen Dom0 on AMD Trinity systems Borislav Petkov
2012-06-06 20:07 ` Konrad Rzeszutek Wilk
2012-06-06 22:00 ` H. Peter Anvin
2012-06-07 7:21 ` Borislav Petkov
2012-06-07 7:49 ` Andre Przywara [this message]
2012-06-07 7:49 ` Andre Przywara
2012-06-07 8:08 ` Greg KH
2012-06-07 8:18 ` Andre Przywara
2012-06-07 8:18 ` Andre Przywara
2012-06-07 13:25 ` [GIT PULL] x86, CPU, AMD: Cleanup AMD-specific MSR-rw users Borislav Petkov
2012-06-07 13:25 ` Borislav Petkov
2012-06-07 16:27 ` [PATCH 3/4] x86, AMD: Fix crash as Xen Dom0 on AMD Trinity systems H. Peter Anvin
2012-06-07 22:00 ` [tip:x86/cpu] x86, cpu, amd: " tip-bot for Andre Przywara
2012-06-01 14:52 ` [PATCH 4/4] x86, CPU, AMD: Deprecate AMD-specific MSR variants Borislav Petkov
2012-06-06 20:07 ` Konrad Rzeszutek Wilk
2012-06-07 22:01 ` [tip:x86/cpu] x86, cpu, amd: " tip-bot for Borislav Petkov
2012-06-01 14:53 ` [PATCH 0/4] x86, CPU, AMD: Cleanup AMD-specific MSR-rw users H. Peter Anvin
2012-06-01 14:57 ` Borislav Petkov
2012-06-01 15:06 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FD05CED.60905@amd.com \
--to=andre.przywara@amd.com \
--cc=JBeulich@suse.com \
--cc=andreas.herrmann3@amd.com \
--cc=bp@amd64.org \
--cc=hpa@zytor.com \
--cc=jacob.shin@amd.com \
--cc=jeremy@goop.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.