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

[Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>]

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
   - 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..)

Thanks,
-Aravind.