From: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: boris.ostrovsky@oracle.com, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [PATCH] x86, amd_ucode: Safeguard against #GP
Date: Tue, 27 May 2014 13:26:09 -0500 [thread overview]
Message-ID: <5384D8C1.5090004@amd.com> (raw)
In-Reply-To: <537F01470200007800015292@mail.emea.novell.com>
On 5/23/2014 1:05 AM, Jan Beulich wrote:
>>>> On 22.05.14 at 17:59, <aravind.gopalakrishnan@amd.com> wrote:
>> On 5/22/2014 3:44 AM, Jan Beulich wrote:
>>>>>> On 21.05.14 at 23:28, <aravind.gopalakrishnan@amd.com> wrote:
>>>> When HW tries to load a corrupted patch, it generates #GP
>>>> and hangs the system. Use wrmsr_safe instead so that we
>>>> fail to load microcode gracefully.
>>>>
>>>> Example on a Fam15h system-
>>>> (XEN) microcode: CPU0 collect_cpu_info: patch_id=0x6000626
>>>> (XEN) microcode: CPU0 size 7870, block size 2586 offset 76 equivID
>>>> 0x6012 rev 0x6000637
>>>> (XEN) microcode: CPU0 found a matching microcode update with version
>>>> 0x6000637 (current=0x6000626)
>>>> (XEN) traps.c:3073: GPF (0000): ffff82d08016f682 -> ffff82d08022d9f8
>>>> (XEN) microcode: CPU0 update from revision 0x6000637 to 0x6000626 failed
>>>>
>>>> Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
>>>> ---
>>>> xen/arch/x86/microcode_amd.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/xen/arch/x86/microcode_amd.c b/xen/arch/x86/microcode_amd.c
>>>> index e83f4b6..23637e2 100644
>>>> --- a/xen/arch/x86/microcode_amd.c
>>>> +++ b/xen/arch/x86/microcode_amd.c
>>>> @@ -191,7 +191,7 @@ static int apply_microcode(int cpu)
>>>>
>>>> spin_lock_irqsave(µcode_update_lock, flags);
>>>>
>>>> - wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)hdr);
>>>> + wrmsr_safe(MSR_AMD_PATCHLOADER, (unsigned long)hdr);
>>> I think you shouldn't ignore the "return" value here.
>> Not sure I understand..
>> Do you mean you want to capture return value and bubble it up? maybe
>> print a debug message too?
> Yes.
>
>> Since we check if patch application succeeded using -
>> if ( rev != hdr->patch_id )
>> and return a error val here, would this not be sufficient?
> It might, but I'm of the opinion that errors should never be ignored
> _and_ be detected as early as possible.
>
>
Have addressed above issues and sending out V2 with Boris' Reviewed-by tag.
Thanks,
-Aravind.
prev parent reply other threads:[~2014-05-27 18:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-21 21:28 [PATCH] x86, amd_ucode: Safeguard against #GP Aravind Gopalakrishnan
2014-05-21 21:51 ` Boris Ostrovsky
2014-05-21 22:08 ` Andrew Cooper
2014-05-22 15:53 ` Aravind Gopalakrishnan
2014-05-22 15:56 ` Andrew Cooper
2014-05-22 15:59 ` Aravind Gopalakrishnan
2014-05-22 8:44 ` Jan Beulich
2014-05-22 15:59 ` Aravind Gopalakrishnan
2014-05-23 6:05 ` Jan Beulich
2014-05-27 18:26 ` Aravind Gopalakrishnan [this message]
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=5384D8C1.5090004@amd.com \
--to=aravind.gopalakrishnan@amd.com \
--cc=JBeulich@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xen.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).