From: Borislav Petkov <bp@alien8.de>
To: suravee.suthikulpanit@amd.com
Cc: herrmann.der.user@googlemail.com, jacob.w.shin@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86, microcode, AMD: Fix patch level reporting for family15h
Date: Fri, 27 Sep 2013 00:13:22 +0200 [thread overview]
Message-ID: <20130926221322.GC10123@pd.tnic> (raw)
In-Reply-To: <1380232472-2589-1-git-send-email-suravee.suthikulpanit@amd.com>
On Thu, Sep 26, 2013 at 04:54:32PM -0500, suravee.suthikulpanit@amd.com wrote:
> From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>
> On AMD family15h, applying microcode patch on the a core (core0)
> would also affect the other core (core1) in the same compute unit.
> The driver would skip applying the patch on core1, but it still
> need to update kernel structures to reflect the proper patch level.
>
> The current logic is not updating the struct ucode_cpu_info.cpu_sig.rev
> of the skipped core. This causes the /sys/devices/system/cpu/cpu1/microcode/version
> to report incorrect patch level as shown below:
>
> [ 10.708841] microcode: CPU0: new patch_level=0x0600063d
> [ 10.714256] microcode: CPU1: patch_level=0x06000626
> [ 10.719345] microcode: CPU2: patch_level=0x06000626
> [ 10.748095] microcode: CPU2: new patch_level=0x0600063d
> [ 10.753365] microcode: CPU3: patch_level=0x06000626
> [ 10.758264] microcode: CPU4: patch_level=0x06000626
> [ 10.786999] microcode: CPU4: new patch_level=0x0600063d
Actually, this is collect_cpu_info_amd()'s normal operation and shows
that there's no need to apply a microcode patch on the odd core since
the even core's ucode has been updated.
Actually you need something like that:
$ grep . cpu?/microcode/version
cpu0/microcode/version:0x6000822
cpu1/microcode/version:0x600081f
cpu2/microcode/version:0x6000822
cpu3/microcode/version:0x600081f
cpu4/microcode/version:0x6000822
cpu5/microcode/version:0x600081f
cpu6/microcode/version:0x6000822
cpu7/microcode/version:0x600081f
which shows the bug. Other than that, the patch is correct so please fix
the commit message and add x86@kernel.org to CC on the next submission
so that it gets picked by x86 people.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
next prev parent reply other threads:[~2013-09-26 22:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-26 21:54 [PATCH] x86, microcode, AMD: Fix patch level reporting for family15h suravee.suthikulpanit
2013-09-26 22:13 ` Borislav Petkov [this message]
2013-09-26 23:06 ` Andreas Herrmann
2013-09-26 23:18 ` Suravee Suthikulpanit
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=20130926221322.GC10123@pd.tnic \
--to=bp@alien8.de \
--cc=herrmann.der.user@googlemail.com \
--cc=jacob.w.shin@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=suravee.suthikulpanit@amd.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.