Re: [Xen-devel] Xen4.2 S3 regression?

[Ben Guthro <ben@xxxxxxxxxx>]

ACK.

I now see microcode updates for both CPUs.

[   47.612719] Disabling non-boot CPUs ...

(XEN) Preparing system for ACPI S3 state.

(XEN) Disabling non-boot CPUs ...

(XEN) Breaking vcpu affinity for domain 0 vcpu 1

(XEN) Entering ACPI S3 state.

(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1 extended MCE MSR 0

(XEN) CMCI: CPU0 has no CMCI support

(XEN) CPU0: Thermal monitoring enabled (TM2)

(XEN) Finishing wakeup from ACPI S3 state.

(XEN) microcode: CPU0 updated from revision 0x60c to 0x60f, date = 2010-09-29 

(XEN) Enabling non-boot CPUs  ...

(XEN) Booting processor 1/1 eip 8a000

(XEN) Initializing CPU#1

(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K

(XEN) CPU: L2 cache: 3072K

(XEN) CPU: Physical Processor ID: 0

(XEN) CPU: Processor Core ID: 1

(XEN) CMCI: CPU1 has no CMCI support

(XEN) CPU1: Thermal monitoring enabled (TM2)

(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06

(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date = 2010-09-29 

[   47.720054] ACPI: Low-level resume complete

On Thu, Sep 27, 2012 at 11:25 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:

>>> On 27.09.12 at 14:12, Ben Guthro <ben@xxxxxxxxxx> wrote:
> On Thu, Sep 27, 2012 at 3:38 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:

>> > (XEN) microcode: collect_cpu_info for CPU0
>> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
>> > (XEN) microcode: collect_cpu_info for CPU1
>> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60f
>>
>> And in the end we see that both cores run on different revisions.
>>
>>
> very interesting. I had overlooked that.

Could you give the below patch a try?

Jan

x86/ucode: fix Intel case of resume handling on boot CPU

Checking the stored version doesn't tell us anything about the need to
apply the update (during resume, what is stored doesn't necessarily
match what is loaded).

Note that the check can be removed altogether because once switched to
use what was read from the CPU (uci->cpu_sig.rev, as used in the
subsequent pr_debug()), it would become redundant with the checks that
lead to microcode_update_match() returning the indication that an
update should be applied.

Note further that this was not an issue on APs since they start with
uci->mc.mc_intel being NULL.

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

--- a/xen/arch/x86/microcode_intel.c
+++ b/xen/arch/x86/microcode_intel.c
@@ -261,8 +261,6 @@ static int get_matching_microcode(const
     }
     return 0;
  find:
-    if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >= mc_header->rev )
-        return 0;
     pr_debug("microcode: CPU%d found a matching microcode update with"
              " version %#x (current=%#x)\n",
              cpu, mc_header->rev, uci->cpu_sig.rev);

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel