Re: [PATCH V3] x86, amd_ucode: Support multiple container files appended together

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

On 06/26/2014 05:55 PM, Aravind Gopalakrishnan wrote:
> On 6/26/2014 3:00 PM, Boris Ostrovsky wrote:
>>
>>>
>>> The process(,scripts) to create containers ensure that we only have 
>>> patches for f10h-f14h on 'microcode_amd.bin'
>>> and patches for f15h models (could be different model/stepping 
>>> values) on microcode_amd_fam15h.bin
>>>
>>> So it is safe to assume that we we only have a matching equiv_id in 
>>> only one of the containers.
>>
>> The trouble is that if I have two files in my hands, both called 
>> microcode_amd_fam15h.bin, I don't know which one is the more 
>> up-to-date (would be nice to have a tool to print file info).
>>
>> Of course, one can argue that in that case I shouldn't be using 
>> neither but HW makes its own verification of patches so in principle 
>> trying both should be safe (provided that SW tries not to load older 
>> revision).
>>
> Hmm, yeah... But this is a pretty contrived case and I'm still not 
> completely convinced this is something we should handle..
> Here are my thoughts:
> - If such a case arises, one can just pull the latest containers which 
> are published
>   - here: 
> https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/amd-ucode 
>
>   - and here: http://www.amd64.org/microcode.html
>   - distros also keep themselves updated by pulling the binaries from 
> above links
> - We can add documentation notes stating to the effect that 
> users(sysadmins) are better off not concatenating two containers of 
> same processor family.
>   - It won't break anything, but you just might end up on a 
> not-so-latest microcode patch level


AFAIK the code always picks the latest version of the patch.


>   - And also point to above links to resolve such deadlock situations
> - If you would still prefer that we handle this case, then we probably 
> should not do it as you described.
>   - The proper way would be to go back to the start of the 1st while 
> loop.
>     - Because we can go back to find_equiv_cpu_id() and take things 
> from there again..
>     - So, more logic rework..
>  (I'm ok with re-working the code, but do let me know if this a case 
> we should care for..)

I think it's worth doing.

-boris