Re: pvops microcode support for AMD FAM >= 15

[Boris Ostrovsky <boris.ostrovsky@amd.com>]

On 12/05/2012 12:02 PM, Jan Beulich wrote:
>>>> On 05.12.12 at 17:48, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
>> On 12/05/2012 07:43 AM, Ian Campbell wrote:
>>> I've just tried this on a fam 15h and I get:
>>>
>>>           (XEN) microcode: collect_cpu_info: patch_id=0x6000626
>>>           (XEN) microcode: size 5260, block size 2592, offset 60
>>>           (XEN) microcode: CPU0 found a matching microcode update with
>> version 0x6000629 (current=0x6000626)
>>>           (XEN) microcode: CPU0 updated from revision 0x6000626 to 0x6000629
>>>
>>>           (XEN) microcode: collect_cpu_info: patch_id=0x6000629
>>>           (XEN) microcode: size 5260, block size 2592, offset 60
>>>           (XEN) microcode: size 5260, block size 2592, offset 2660
>>>           (XEN) microcode: CPU1 patch does not match (patch is 6101, cpu base
>> id is 6012)
>>>
>>>           (XEN) microcode: collect_cpu_info: patch_id=0x6000626
>>>           (XEN) microcode: size 5260, block size 2592, offset 60
>>>           (XEN) microcode: CPU2 found a matching microcode update with
>> version 0x6000629 (current=0x6000626)
>>>           (XEN) microcode: CPU2 updated from revision 0x6000626 to 0x6000629
>>>
>>>           (XEN) microcode: collect_cpu_info: patch_id=0x6000629
>>>           (XEN) microcode: size 5260, block size 2592, offset 60
>>>           (XEN) microcode: size 5260, block size 2592, offset 2660
>>>           (XEN) microcode: CPU3 patch does not match (patch is 6101, cpu base
>> id is 6012)
>>>
>>>           (XEN) microcode: collect_cpu_info: patch_id=0x6000626
>>>           (XEN) microcode: size 5260, block size 2592, offset 60
>>>           (XEN) microcode: CPU4 found a matching microcode update with
>> version 0x6000629 (current=0x6000626)
>>>           (XEN) microcode: CPU4 updated from revision 0x6000626 to 0x6000629
>>>
>>>           (XEN) microcode: collect_cpu_info: patch_id=0x6000629
>>>           (XEN) microcode: size 5260, block size 2592, offset 60
>>>           (XEN) microcode: size 5260, block size 2592, offset 2660
>>>           (XEN) microcode: CPU5 patch does not match (patch is 6101, cpu base
>> id is 6012)
>>>
>>>           (XEN) microcode: collect_cpu_info: patch_id=0x6000626
>>>           (XEN) microcode: size 5260, block size 2592, offset 60
>>>           (XEN) microcode: CPU6 found a matching microcode update with
>> version 0x6000629 (current=0x6000626)
>>>           (XEN) microcode: CPU6 updated from revision 0x6000626 to 0x6000629
>>>
>>>           ....
>>>
>>> It seems like it is applying successfully on only the even numbered
>>> cpus. Is this because the odd and even ones share some execution units
>>> and therefore share microcode updates too? IOW update CPU0 also updates
>>> CPU1 under the hood.
>>>
>>> If so then we probably want to teach Xen about this, although at least
>>> for now though it would mean that the microcode is actually getting
>>> applied despite the messages.
>>
>> On fam15h cores are grouped in pairs into compute units (CUs) and cores
>> in CUs share microcode engine. So yes, you are right --- when we apply a
>> patch to one core, the other one sees the update.
>>
>> I believe at some point we thought about making code smarter and
>> applying patch only on one core in a CU but then decided against it
>> because of some corner cases, For example, there are parts with
>> single-core CUs and it is not out of question that some BIOSes may not
>> enumerate them correctly. Yes, we can figure this all out in the code
>> but we didn't feel that adding complexity was worth it.
>
> But all of this shouldn't lead to equivalent ID mismatches, should
> it? It ought to simply find nothing to update...


The patch file (/lib/firmware/amd-ucode/microcode_amd_fam15h.bin) may 
contain more than one patch. The driver goes over this file patch by 
patch and tries to see whether to apply it.

I think what happened in Ian's case was that the patch file contained 
two patches --- one for this processor (ID 6012) and another for a 
different processor (ID 6101). (Both are family 15h but different revs).

The driver applied the first patch on core 0. Then, on core 1, the code 
tried the first patch (at file offset 60) and noticed that it is already 
applied. So it continued to the next patch (at offset 2660) which is not 
meant for this processor, thus generating the "does not match" message.

So we have at least a problem in how the error is reported to the log -- 
it is confusing. I'll try to make it more understandable.

And maybe core 1 shouldn't go into the second patch in the first place 
because it already found a patch for this processor (but decided that it 
is not needed based on patch ID).


-boris