Re: [PATCH] x86, microcode, AMD: Fix patch level reporting for family15h

From: Suravee Suthikulpanit
Date: Thu Sep 26 2013 - 19:18:52 EST


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@xxxxxxx wrote:
From: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/