From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
To: Andreas Herrmann <herrmann.der.user@googlemail.com>
Cc: <jacob.w.shin@gmail.com>, <linux-kernel@vger.kernel.org>,
Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH] x86, microcode, AMD: Fix patch level reporting for family15h
Date: Thu, 26 Sep 2013 18:18:31 -0500 [thread overview]
Message-ID: <5244C0C7.80109@amd.com> (raw)
In-Reply-To: <20130926230623.GA1764@alberich>
On 9/26/2013 6:06 PM, Andreas Herrmann wrote:
> On Fri, Sep 27, 2013 at 12:13:22AM +0200, Borislav Petkov wrote:
>> 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.
> Hmm, I think Boris is right, above messages are just logging what
> happened during µcode update. I think the patch_level in "CPU1:
> patch_level=0x06000626" is based on c->microcode which is updated
> shortly after this message was printed.
>
> I assume with your patch, above message won't look different but just
> the contents in /sys/devices/system/cpu/cpu1/microcode/version will
> show the correct version, right?
>
>
> Andreas
>
Yes, the message in dmesg is still showing the same. Only the sysfs...
version is now fixed.
Suravee
prev parent reply other threads:[~2013-09-26 23:18 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
2013-09-26 23:06 ` Andreas Herrmann
2013-09-26 23:18 ` Suravee Suthikulpanit [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=5244C0C7.80109@amd.com \
--to=suravee.suthikulpanit@amd.com \
--cc=bp@alien8.de \
--cc=herrmann.der.user@googlemail.com \
--cc=jacob.w.shin@gmail.com \
--cc=linux-kernel@vger.kernel.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 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.